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CHAPTER  ONE 


$1.1  Introduction 

The  creation  of  a compiler  for  a specific  language  and  target  machine  is  an 
arduous  process.  It  is  not  uncommon  to  invest  several  years  In  the  production  of 
an  acceptable  compiler;  the  excellent  compilers  available  for  PL/I  on  MULTICS  and 
System  370  evolved  over  a decade  or  more.  With  the  rapid  development  of  new 
computing  hardware  and  the  proliferation  of  high-level  languages,  such  an 
Investment  is  no  longer  practical,  especially  if  there  is  little  carry-over  from  one 
Implementation  to  the  next. 

Compiler  writers  currently  suffer  from  the  same  malady  as  the  shoemaker’s 
children:  they  seem  to  be  the  last  to  benefit  from  the  Improvements  in  compiler 
language  technology  that  problem-oriented  language  processors  have  Incorporated. 
The  current  research  has  been  directed  towards  providing  the  compiler  writer  with 
the  same  high-level  tools  that  he  provides  for  others.  In  an  effort  to  automate 
compiler  production,  systems  have  been  developed  to  automatically  generate  those 
portions  of  the  compiler  which  translate  the  source  language  program  Into  an 
Internal  form  suitable  for  code  generation.  These  systems  have  enhanced 
portability  and  extensibility  of  the  resultant  compiler  without  a significant 
degradation  In  Its  performance.  The  final  phases  of  a compiler,  those  concerned 
with  code  generation,  are  now  coming  under  a similar  scrutiny.  Many  different 
approaches  are  possible  (see  $1.4);  this  thesis  addresses  the  Issue  of  providing  a 
specification  of  a code  generator.  Such  a specification  is  constructed  by  the  code 
generator  designer  within  a framework  provided  by  an  Intermediate  language  (IL) 
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and  a metalntar prater.  The  Intermediate  language  Is  used  as  the  Internal 
representation  of  the  code  generator  - the  Initial  input  (provided  by  the  first  phase 
of  the  compiler)  Is  a source  language  program  expressed  as  an  IL  program;  the  final 
output  Is  the  IL  representation  of  the  target  machine  program.  The  metainterpreter 
has  a detailed  understanding  of  the  semantics  of  IL  programs  and  Is  capable  of 
performing  many  transformations  and  optimizations  on  those  programs.  The 
semantics  of  IL  are  limited  to  concepts  common  to  many  languages  and  machines: 
flow  of  control  and  the  management  of  names  and  values  are  the  only  primitive 
concepts.  Specification  of  machine-  and  language-dependent  semantics  (e.g.,  the 
semantics  of  Individual  operators)  are  provided  by  the  designer  In  the  form  of  a 
transformation  catalogue,  in  essence,  the  semantics  of  IL  serve  as  common  ground 
on  which  the  designer  (through  the  transformation  catalogue)  "explains"  the  source 
language  and  target  machine  to  the  metainterpreter  which  then  performs  the 
appropriate  translation.  This  "explanation”  Is  in  terms  of  a step-by-step  syntactic 
manipulation  of  the  IL  program;  each  transformation  accumulates  additional 
Information  for  the  metainterpreter  or  provides  possible  translations  for  IL 
statements  which  are  not  yet  target  machine  Instructions.  Since  the 
metainterpreter  incorporates  many  of  the  optimizations  commonly  performed  by 
compilers,  the  specification  need  not  supply  detailed  implementation  descriptions  of 
these  operations. 

One  can  envision  several  distinct  uses  for  such  a specification: 

e as  a convenient  way  of  replacing  English  descriptions  of  an  algorithm 
(much  the  same  way  a BNF  documents  syntactically  legal  programs); 

a as  a program  which,  along  with  a specific  Input  string,  can  be 
Interpreted  to  produce  an  acceptable  translation  (e.g.,  syntax 
directed  translation  based  on  a parse  of  the  Input  string);  or 

a as  an  input  to  a system  which  automatically  constructs  a code 
generator  (similar  to  the  various  specifications  fed  to  a compiler- 
compiler). 
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Each  successive  use  requires  a more  thorough  understanding  of  the  specification 
but  repays  this  investment  with  a corresponding  increase  in  the  degree  of 
automation  achieved.  The  increase  is  based  for  the  most  part  on  a better 
understanding  of  the  interaction  between  components  of  the  specification. 
Automatic  creation  of  a code  generator  from  a specification  would  require 
extensive  analysis  of  these  Interactions,  a capability  only  now  just  emerging  from 
artificial  intelligence  research  on  program  synthesis  [Barstow].  Fortunately  most  of 
the  analytical  mechanism  required  is  in  addition  to  the  facilities  provided  by  the 
metainterpreter  and  intermediate  language  - It  Is  reasonable  to  expect  that  future 
research  will  be  able  to  extend  the  framework  described  In  the  preceding 
paragraph  to  allow  automatic  construction  of  a code  generator.  This  thesis 
concentrates  on  developing  the  framework  to  the  point  where  it  can  be  used 
interpretively  (as  suggested  by  the  second  use):  inplemented  In  a straightforward 
fashion,  the  metainterpreter  can  perform  the  translation  by  alternately  applying 
transformations  from  the  catalogue  and  optimizing  the  updated  IL  program.  While 
this  approach  is  admittedly  less  efficient  than  current  code  generators,  it 
represents  a significant  step  towards  separating  machine  and  language 
dependencies  In  a declarative  form  (the  transfornation  catalogue)  from  general 
knowledge  about  code  generation  (embodied  in  the  metainterpreter). 

The  following  section  provides  a brief  overview  of  the  tasks  confronting  a 
code  generator.  $1.3  presents  a summary  of  the  salient  features  of  IL,  the 
transformation  catalogue,  and  the  metainterpreter.  In  $1.4,  related  work  is 
discussed  with  an  eye  towards  providing  a genealogy  for  the  research  reported 
here.  Finally,  $1.6  outlines  the  organization  of  the  remainder  of  the  thesis. 
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$1.2  Setting  the  stag* 

Before  embarking  on  a discussion  of  the  proposed  formalism,  let  us  first 

characterize  the  nature  of  the  task  we  wish  to  describe: 

code  generation  Is  the  translation  of  a representation  (In  some 
Intermediate  language)  of  the  computations  specified  In  the  original 
source  language  program  into  a sequence  of  Instructions  to  be 
directly  executed  by  the  target  machine. 

The  Idea,  of  course,  is  that  by  executing  the  resulting  sequence  of  machine 

Instructions  the  target  machine  will  carry  out  the  specified  computation.  The 

remainder  of  this  section  outlines  the  tasks  confronting  a code  generator;  our 

objective  is  to  sketch  the  variety  of  knowledge  needed  for  making  decisions  during 

code  generation  and  how  current  code  generators  embody  this  knowledge. 

An  optimizing  code  generator  Is  organized  around  three  main  tasks: 

machine-independent  optimization 
i 

translation  to  target  machine  instructions 
i 

machine-dependent  optimization. 

Machine-Independent  optimizations  Include  global  flow  analysis,  constant 
propagation,  common  subexpression  and  redundant  computation  elimination,  etc.  - 
these  transformations  modify  the  semantic  tree,  producing  a new  tree  which  is 
strictly  equivalent  (l.e.,  equivalent  regardless  of  the  choice  of  target  machine). 
Certain  of  these  transformations  do  make  general  assumptions  about  the  target 
machine  architecture;  for  Instance,  constant  propagation  assumes  that  It  is  more 
efficient  to  access  a constant  than  a variable.  The  more  sophisticated  code 
generators  [Wulf]  do  not  actually  modify  the  semantic  tree  - they  maintain  a list  of 
alternatives  for  each  node  In  the  tree^,  postponing  the  choice  of  transformation 

t They  do  not,  however,  list  all  possible  alternatives  as  this  would  result  in  the 
combinatorial  growth  of  the  semantic  tree.  Searching  the  full  tree  for  the  optimal 
program  accounts  for  the  NP-completeness  of  the  code  generation  problem  [Aho77]. 
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until  the  translation  phase. 

The  translation  to  target  machine  instructions  takes  place  In  several  stages: 

(I)  Storage  is  allocated  for  variables  and  constants  used  in  the  source 
program.  The  semantics  of  the  program  often  require  specific 
allocation  strategies  (e.g.,  jtacks). 

(II)  Algorithms  which  Implement  the  required  computations  (FOR-loops, 
subroutine  calls,  etc.)  are  chosen. 

(lil)  The  order  in  which  computations  are  to  be  performed  is  determined. 
Through  the  detection  of  redundant  computations,  It  Is  often  possible 
to  permute  the  evaluation  order  and  realize  savings  of  both  time  and 
space  in  the  resulting  code  while  maintaining  the  correctness  of  the 
computation. 

(iv)  Actual  target  machine  instructions  are  generated.  Machine- 
dependent  considerations  (such  as  locations  of  operands  for 
particular  operations,  the  lack  of  symmetrical  operations,  etc.)  enter 
at  this  level. 

From  the  many  possible  transformations  applicable  to  a particular  source  program, 

an  optimizing  code  generator  chooses  some  sjbset  to  produce  the  "best" 

translation.  These  transformations  are  Interdependent  and  an  a prior) 

determination  of  their  combined  effect  Is  difficult. 

Machine-dependent  (peephole)  optimization  [McKeeman,  Wulf:  Chapter  6]  of 

Instruction  sequences  can  be  used  to  improve  the  generated  code  - just  how  much 

Improvement  can  be  made  depends  on  the  sophistication  of  the  translation  phase. 

The  goal  is  to  substitute  more  efficient  instruction  sequences  for  small  portions  of 

the  code.  Examples:  elimination  of  jumps  to  other  jumps  and  code  following 

unconditional  jumps,  use  of  short-address  jumps  (limited  in  how  far  they  can  jump), 

elimination  of  redundant  store-load  sequences,  etc.  This  phase  Is  iterated  until  no 

more  Improvements  can  be  made.  Before  the  reader  dismisses  this  final  phase  as 

"trivial,"  he  should  consider  this  comment  from  [Wulf,  pg.  124f]: 

...  all  the  fancy  optimization  In  the  world  Is  not  nearly  as  Important  as 
careful  and  thorough  exploitation  of  the  target  machine...  It  is 
difficult  to  determine  to  what  extent  [this  final  phase]  would  be 
needed  If  more  complete  algorithms,  rather  than  heuristics,  existed  in 
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•arller  phases  of  the  compiler.  However,  since  some  of  the 
operations  of  [this  final  phase]  exist  simply  because  the  requisite 
Information  does  not  exist  earlier,  we  suspect  that  there  will  always 
be  a role  for  a [similar  module]  ... 

It  should  be  noted  that  relatively  few  of  the  transformations  mention  sd 
above  are  uniformly  applicable.  Unfortunately,  the  conventional  control  structures 
upon  which  extant  code  generators  are  based  preclude  a trial-and-error  approach 
to  optimization.  The  programmer,  using  his  knowledge  of  the  target  machine 
architecture,  must,  out  of  necessity,  incorporate  In  the  code  generator  either  some 
subset  of  the  applicable  transformations  or  heuristics  to  select  the  "best" 
transformation  at  specific  points  In  the  code  generation  process.  These  heuristics 
base  their  decisions  on  a local  examination  of  the  tree;  more  far-reaching 
consequences  are  difficult  to  determine  - thus,  most  heuristics  "work"  for  only  a 
subset  (albeit  large)  of  the  possible  programs.  Although  the  compromises  Inherent 
In  heuristics  serve  primarily  to  reduce  the  amount  of  computation  needed  to 
complete  the  translation,  they  also  embody  knowledge  helpful  In  the  generation  of 
code.  Some  of  these  transformations  are  of  general  use  In  that  they  are 
Independent  of  both  the  Intermediate  representation  and  the  target  machine;  these 
transformations  form  a nucleus  of  knowledge  for  the  portable  code  generation 
system. 

§1.3  Introduction  to  IL/ML 

The  framework  for  the  specification  of  code  generators  provided  by  the 
IL/ML  system  has  three  basic  components: 

e an  Intermediate  language  (IL)  which  serves  as  the  internal 
representation  for  all  stages  of  the  translation.  At  any  given  moment, 
the  IL  program  embodies  all  the  text,  symbol  table,  and  state 
Information  accumulated  by  the  code  generator  up  to  that  point  In  the 
translation. 

e a transformation  catalogue  whose  component  transformations  are 
expressed  In  a context-sensitive  pattern-matching  metalanguage  (ML) 
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as  pattern/replacement  pairs.  The  pattern  specifies  the  context  of 
the  transformation  as  an  IL  program  fragment;  the  replacement  is 
another  fragment  to  be  substituted  for  the  matched  fragment. 

e a metainterpreter  Incorporating  a fairly  complete  repertoire  of 
machine-  and  language-independent  optimization  algorithms  for  IL 
programs.  The  metainterpreter  is  also  capable  of  selecting  and 
applying  transformations  from  the  transformation  catalogue. 

Within  this  framework,  code  generation  may  be  viewed  as  follows^:  the 

transformation  catalogue  is  searched  by  the  metainterpreter  until  a pattern  Is  found 

that  matches  some  fragment  of  the  current  IL  program,  then  the  corresponding 

replacement  is  substituted  for  the  matched  fragment  creating  an  updated  version 

of  the  IL  program.  Next,  the  metainterpreter  optimizes  the  new  version  of  the 

program  utilizing  new  information  and  opportunities  presented  by  the  transformation. 

This  cycle  is  repeated  until  no  further  matches  can  be  found,  at  which  point  the 

translation  is  completed.  The  simplicity  of  the  mechanism,  along  with  the  modularity 

of  the  transformation  data  base,  make  this  an  attractive  basis  for  a code  generator 

specification. 

Only  concepts  common  to  most  machine  and  source  language  programs  have 
been  incorporated  into  IL  and  the  metainterpreter  - concepts  specific  to  a machine 
or  language  are  introduced  by  the  designer  through  the  transformation  catalogue. 
Many  of  these  new  concepts  need  never  be  related  to  the  primitives  of  IL:  they 
can  be  Introduced  Into  the  IL  program  as  attributes  of  some  component  of  the  IL 
program  where  they  can  be  referenced  by  transformations.  The  semantics  of 
these  attributes  are  established  by  the  role  they  play  In  various  transformations; 


t This  description  is  only  a conceptual  model;  In  a code  generator  constructed 
from  the  specification,  the  decisions  Inherent  In  choosing  and  applying  a 
transformation  would  have  been  ordered  by  the  metacompiler  and  Incorporated  In 
the  organization  of  the  code  generator  (actual  searching  would  be  seldom  be  done). 
Some  decisions  would  be  made  during  the  construction  of  the  code  generator, 
others  would  be  embodied  as  decision  trees  and  heuristics.  Other  distinctions 
between  interpretation  and  compilation  of  the  specification  are  Ignored  until 
Chapter  6. 
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for  example,  the  concept  of  an  addition  operator  need  only  be  related  to  the 
Integer  and  floating-point  addition  Instructions  of  the  target  machine  - neither  IL  nor 
the  metainterpreter  havt  to  support  addition  as  a primitive  operation.  The  ability  to 
express  source  language  semantics  in  terms  of  other,  simpler  operations  and, 
ultimately.  In  terms  of  target  machine  Instructions  without  recourse  to  some  fixed 
semantics  allows  great  flexibility  without  any  attendant  complexity  In  the 
Intermediate  language  or  metainterpreter. 

But  Isn’t  It  "cheating"  to  require  the  designer  to  spell  out  source  language 
semantics  In  terms  of  target  machine  Instruction  sequences?  Doesn’t  that  raise 
the  objection  to  conventional  code  generators,  viz.  that  a large  investment  is 
necessary  to  redo  the  translations  when  another  target  machine  or  source 
language  Is  to  be  accommodated?  No,  not  really.  There  is  no  "magic"  provided  by 
the  IL/ML  system  - the  semantics  of  the  source  language  and  target  machine  must 
always  be  described  by  the  designer  In  any  truly  language-  and  machine- 
independent  system.  However,  their  most  natural  (and  useful)  description  is  in 
terms  of  one  another  - after  all,  the  designer  In  theory  fully  understands  both  and 
the  simplicity  of  the  IL/ML  system  minimizes  the  need  for  expertise  in  any  other 
language/interpreter.  Moreover,  since  the  metainterpreter  incorporates  the 
necessary  knowledge  about  general  optimization  techniques,  the  overhead  of  the 
description  Is  small  compared  to  coding  a conventional  code  generator.  It  is  true 
that  a more  highly  specified  Intermediate  language  semantics  might  be  more 
appropriate  for  a specific  source  language  and  target  machine,  but  such  constraints 
Impede  the  transition  to  other  languages  and  target  machines  (see  description  of 
abstract  machines  In  $1.4).  Since  IL/ML  Is  to  be  a general  purpose  code 
generation  system,  such  constraints  have  been  avoided. 
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$1.3.1  A syntactic  modal  of  coda  generation 

One  of  the  most  useful  discoveries  of  artificial  intelligence  research  is  that 
complicated  semantic  manipulations  can  be  accomplished  with  step-by-step 
syntactic  manipulation  of  an  appropriately  chosen  data  base  (see,  for  example, 
[Hewitt]).  This  section  explores  the  application  of  this  approach  to  the  process  of 
code  generation.  The  objective  of  this  exploration  Is  to  provide  a different 
perspective  of  the  IL/ML  system  - hopefully  this  will  lead  to  a better  designed 
transformation  catalogue. 

One  can  characterize  code  generation  as  a consecutive  sequence  of 
transformations  chosen  from  the  transformation  catalogue  and  applied  to  an 
Intermediate  language  Input  string: 

intermediate  "*  a1  * *2  '"  "*  *n  starget  machine' 

’target  machine  '®  not  n«c®ssarlly  unique;  thus,  the  code  generation  algorithm  may 
have  to  choose  among  many  translations.  If  the  translation  uses  an  abstract 
machine  then  we  will  have 

’intermediate  * ®1  "*  *k-1  ®AM  ®k+1  * **  ®n  "*  ’target  machine' 

The  transformations  leading  to  sA^  are  Independent  of  the  target  machine;  the 

transformations  following  s^  are  machine  dependent.  If  we  group  transformations 
according  to  the  code  generation  steps  they  describe  (e.g.,  storage  allocation, 
register  assignment,  etc),  each  group  describes  the  translation  of  programs  for  a 
particular  abstract  machine  Into  programs  for  another.  By  defining  a hierarchy  of 
abstract  machines,  the  designer  can  limit  the  Impact  of  a particular  feature  of  the 
target  machine  to  a few  transformations.  This  type  of  organization  of  the 
transformation  catalogue  leads  to  a highly  modular  specification. 

As  was  mentioned  above,  the  resulting  machine  language  program  is  not 
always  unique  - In  order  to  be  able  to  decide  among  competing  translations,  it  Is 
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necessary  to  introduce  some  measure  (m)  of  a program’s  cost: 

m:  s -*  R u «*. 

This  totally  ordered  measure  Is  to  reflect  the  optimality  of  the  translation;  the 
smaller  the  measure,  the  more  optimal  the  translation.  Note  that  tht>  measure  Is  not 
defined  (m(s’)  ■ «)  for  Intermediate  language  strings  (s’)  that  do  not  represent  a 
completed  translation.  Typically  this  measure  Is  computed  from  the  values  of 
attributes  of  the  statements  in  the  Anal  program:  It  Is  up  to  the  designer  to  ensure 
that  each  statement  Is  assigned  these  attributes  - If  some  statement  does  not 
have  the  appropriate  attributes  defined,  the  measure  for  that  IL  program  will  be 
undefined.  The  final  choice  for  a given  input  string  s and  measure  m Is  the  set  of 
"optlmalH  translations  given  by 

0m(s)  s { s’  | s * s'  and  for  all  s"  [s  * a"  implies  m(s’)  s m(s”)]  }. 

Note  that  we  restrict  our  notion  of  optimality  to  those  strings  which  can  be  actually 
derived  from  the  Initial  program  (s)  by  repeated  applications  of  transformations  from 
the  transformation  catalogue  (i.e.,  a " s’, s”).  It  Is  possible  that  semantically 
equivalent  strings  exist  which  are  more  optimal  but  which  may  not  be  discovered 
because  of  some  inadequacy  In  the  transformation  catalogue.  In  some  sense  this 
Inadequacy  Is  Intrinsic  since  the  semantic  equivalence  problem  Is  In  general 
unsolvable  [Aho70]. 

In  our  syntactic  view  of  code  generation,  ws  have  set  forth  two  tasks  for 
the  code  generator.  First,  It  must  produce  a set  of  translations  for  the  given  Input 
string  that  meet  certain  basic  criteria:  e.g.,  they  must  be  well-formed  machine- 
language  programs  (only  these  should  have  the  correct  attributes  needed  to 
compute  the  measure).  Second,  It  must  select  one  of  these  translations  as  the 
translation.  This  selection  is  based  on  the  optimality  of  the  translation  as  well  as 
other  constraints  the  user  may  supply  at  compile  time  (e.g.,  upper  bounds  on  space 
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•nd/or  execution  speed).  The  filtering  process  Is  an  expensive  one  as  It  means 
discarding  completed  translations  - the  more  restrictive  the  complle-time 
constraints,  the  more  programs  may  have  to  be  discarded  before  a satisfactory 
translation  Is  encountered.  An  alternative  approach  Is  to  Include  these  criteria  as 
part  of  transformations  In  the  catalogue,  using  contextual  information  to  disqualify 
transformations  which  result  In  a violation.  Thus  unproductive  translations  ere 
aborted  before  the  effort  is  expended  to  complete  them.  The  decision  to  Include 
essentially  all  constraints  as  transformations  allows  a parsimonious  description  of 
acceptable  translations  at  the  cost  of  additional  transformations.  Experiments  with 
automatic  creation  of  a code  generator  from  a set  of  transformations  may  prompt 
us  to  change  our  minds. 

Let  us  take  a moment  to  outline  the  advantages  and  disadvantages  of  this 
approach  to  code  generation.  By  modeling  code  generation  as  a series  of  simple 
syntactic  transformations,  we  have  removed  the  onus  of  specifying  the  order  in 
which  the  transformations  are  to  be  done  - we  have  removed  the  control  structure 
of  the  code  generator.  In  its  place  we  require  that  the  designer  specify  enough 
context  for  each  transformation  to  guarantee  It  will  be  used  only  when  appropriate. 
The  merits  of  this  tradeoff  are  difficult  to  Judge.  For  small  sets  of  transformations 
it  is  simpler  to  omit  the  control  structure  as  It  Is  possible  to  foresee  undesirable 
Interactions  between  the  various  transformations  and  head  them  off  at  the  pass. 
As  the  number  of  transformations  increases.  It  becomes  Increasingly  difficult  to 
account  for  the  global  effect  of  an  additional  transformation.  Adopting  a modular 
organization  for  the  transformations  alleviates  this  problem  - the  use  of  a hierarchy 
of  transformations  (with  little  overlap  between  levels)  supplies  an  Implicit  context 
for  the  transformations  on  a given  level.  There  are  many  syntactic  mechanisms  for 
enforcing  this  modularity;  several  are  presented  In  later  examples.  The  greatest 
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advantage  of  a syntactic  view  of  code  generation  is  that  the  designer  is  not 
encumbered  with  the  details  of  programming  but  is  able  to  deal  at  a higher,  more 
natural  level  In  describing  code  generation.  The  principal  disadvantage  is  the 
current  lack  of  a simple  technique  for  realizing  a code  generator  from  the 
transformations.  To  actually  Implement  a code  generator,  we  will  have  to  make 
explicit  the  Implicit  control  structure  supplied  by  the  context  of  each 
transformation.  Until  this  problem  is  solved,  It  looms  as  the  largest  barrier  to 
accepting  the  syntactic  view  of  code  generation. 

$1.3.2  The  transformation  catalogue  and  metainterpreter 

Since  the  emphasis  in  a specification  Is  on  describing  what  the  code 
generator  is  to  do  rather  than  how  it  Is  to  be  done,  an  effort  has  been  made  to 
distinguish  strategy  from  mechanism.  The  strategic  decisions  made  by  a code 
generator  are  embodied  in  the  transformation  catalogue  and  fall  roughly  into  three 
categories: 

(1)  expansion  of  a high-level  IL  statement  Into  a series  of  more 
elementary  statements; 

(2)  simplification  or  elimination  of  IL  statements  whose  operations  can  be 
performed  at  compile  time; 

(3)  transformations  on  sequences  of  IL  statements,  e.g.,  code  motion  in 
loops,  permutation  of  evaluation  order  to  achieve  better  register 
usage,  peephole  optimizations,  etc. 

The  applicability  of  a transformation  to  a particular  IL  statement  depends  on  the 
context  In  which  that  statement  appears.  In  traditional  code  generators  the 
context  of  an  operation  Is  established  by  two  interdependent  computations: 

e flow  analysis  to  determine  available  expressions,  use-definition 
chaining,  and  live  variables; 

e compile-time  computation  of  values  for  variables  and  intermediate 
results. 

In  a IL/ML  specification,  these  computations  have  been  Incorporated  as  part  of  the 
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context  matching  performed  before  a transformation  is  applied  - the  designer 
never  explicitly  invokes  the  underlying  mechanism,  instead  he  may  deal  directly 
with  values  of  variables,  execution  order  of  IL  statements,  etc.  as  part  of  an  ML 
pattern. 

The  adequacy  of  IL/ML  as  the  basis  for  a code  generator  specification 
hinges  on  the  ability  of  the  pattern  matching  mechanism  to  express  the  desired 
context.  The  pattern  primitives  provided  by  ML  are  based  on  standard  data  flow 
analysis  techniques  [Ullman,  Kildall]  and  do  not  require  extensions  to  the  state  of 
the  art.  Fortunately,  these  standard  techniques  easily  compute  the  information 
required  by  many  common  optimizations.  Combined  with  modest  symbolic 
computation  abilities  (arithmetic  on  Integers,  canonlcallzation  of  expressions,  etc.) 
the  bulk  of  a code  generators'  task  can  be  easily  described  without  further 
mechanism.  Ideally,  It  would  be  nice  to  stop  here  and  rely  on  sequences  of 
transformations  to  Implement  the  more  exotic  transformations  (such  as  Induction 
variable  elimination  or  register  allocation)  which  are  not  currently  incorporated  in 
the  metainterpreter.  Unfortunately,  this  is  an  unreasonable  attitude  in  light  of  the 
complexity  of  current  algorithms  for  performing  these  transformations;  the  resulting 
set  of  transformations,  If  possible  to  construct  at  all,  would  be  so  large  as  to 
intimidate  even  the  most  dedicated  reader  of  the  apeciflcation.  Two  alternatives 
•re 

(1)  to  express  the  kernel  of  the  algorithm  as  a simple  transformation 
(such  as  assigning  a compiler  temporary  a free  register  name)  and 
rely  on  a combinatoric  search  to  try  all  the  possible  alternatives.  A 
clever  metacompiler  might  be  able  to  recognize  these  transformations 
for  what  they  are  and  substitute  one  of  several  heuristics  in  the 
resulting  code  generator. 

(2)  to  Include  built-in  predicates  (in  the  case  of  Induction  variables)  or 
functions  (for  register  allocation)  that  provide  enough  information  for 
a simple  transformation  to  perform  the  desired  translation.  To  ensure 
that  the  specification  does  not  build  in  certain  heuristics  this  scenario 
requires  algorithms  that  always  "work"  (l.e.,  produce  complete  or 
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optimal  results);  for  many  of  tha  transformations  In  quastlon  no  such 
algorithm  ourrantly  axlsta. 

Neither  alternative  Is  completely  satisfactory  and  further  research  la  needed  to 
reach  a conclusion.  It  seems  reasonable  to  expect  an  eventual  resolution  of  this 
Issue  and  there  Is  some  evidence  [Harrison]  that  many  such  optimizations  may  be 
Ignored  without  significantly  degrading  the  usability  of  the  specification.  In  this 
spirit,  the  remainder  of  the  thesis  concentrates  on  the  specification  of  code 
generation  techniques  which  have  a basis  In  flow  analysis  and  its  extensions.  ’ 

$1.4  Relation  to  previous  work  j 

Until  recently,  research  had  focused  on  two  approaches  for  the  specification 
of  code  generators:  the  development  of  high-level  languages  better  adapted  to  the 
writing  of  code  generators  and  the  introduction  of  an  "abstract  machine"  to  further 
simplify  the  code  generation  process.  The  new  high-level  languages  [Young] 
provide  as  primitives  many  of  the  elementary  operations  used  In  code  generation 
such  as  storage  and  register  allocation  and  automatic  management  of  Internal  data 
bases  (e.g.,  the  symbol  table).  The  actual  process  of  code  generation  typically  fills 
in  a user-provided  code  template  with  sundry  parameters  such  as  the  actual 
location  of  the  operands,  etc.  Local  optimization  Is  accomplished  by  special 
constructs  within  the  template  which  allow  testing  for  given  sttrtbutes  of  the 
parameters.  Modularity  of  the  code  generator  Is  Improved  and  much  of  the 
machine-dependent  Information  is  in  descriptive  form.  Of  course,  the  portions  of  the 
code  generation  algorithm  and  the  optimization  mechanism  which  depend  on  the 
semantics  of  the  source  language  or  target  machine  must  still  be  coded  Into 
procedural  form.  The  encoding  of  this  Information  (usually  as  special  cases) 
represents  a large  portion  of  many  optimizing  compilers  [Carter]. 
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The  apparent  dichotomy  between  descriptions  of  the  intermediate  language 
and  the  target  machine  led  to  disparate  mechanisms  for  describing  each.  The  use 
of  an  abstract  machine  (AM)  capitalizes  on  this  dichotomy.  The  operations  of  the 
AM  are  a set  of  low-level  Instructions  based  on  some  simple  architecture.  A code 
generator  based  on  an  AM  [Poole]  performs  two  translations:  first  the  parse  tree  is 
translated  Into  a sequence  of  AM  operations  and  then  each  AM  operation  is,  In  turn, 
expanded  into  a sequence  of  target  Instructions.  The  optimality  of  the  resultant 
code  is  largely  a function  of  how  closely  the  AM  and  the  target  machine  correspond 
and  how  much  work  is  expended  on  the  expansion. 

The  first  AM  was  UNCOL  (universal  computer  oriented  /anguage)  [Steel], 
Introduced  to  solve  the  "mxn  translator"  problem.  Its  proponents  hoped  that  the 
use  of  a common  base  language  would  reduce  the  number  of  modules  needed  to 
translate  m languages  to  n machines  from  mxn  to  m+n;  they  would  translate  a 
program  In  one  of  the  m languages  to  UNCOL  and  then  translate  the  UNCOL  program 
to  one  of  the  n machines.  The  "UN"  in  "UNCOL"  was  their  undoing  as  it  proved 
exceedingly  difficult  to  incorporate  all  the  features  of  existing  languages  and 
machines  Into  the  primitives  of  a single  language.  By  limiting  the  scope  of  the  AM 
to  a class  of  languages  and  machines  [Coleman,  Waite],  it  was  possible  to  achieve 
truly  portable  software  with  a minimum  of  effort.  Current  implementations  fall  Into 
two  categories: 

(a)  The  expansion  Is  guided  by  a description  of  the  target  machine 
[Miller,  Snyder].  The  code  generator  may  be  easily  modified  to 
accommodate  a different  machine;  however,  due  to  the  loss  of 
Information  during  the  translation  to  AM  operations,  It  is  difficult  to 
use  special  features  of  the  target  hardware  to  advantage.  The 
description  language  is  generally  tailored  for  a specific  class  of 
machines  and  cannot  easily  be  augmented. 

(b)  The  expansion  Is  done  by  a program  designed  to  produce  highly 
optimized  code  for  a specific  target  machine  [Richards].  This  end  Is 
achieved  via  a "simulation"  of  the  AM  operations  to  gather  sufficient 
Information  about  the  original  program  to  allow  more  than  local 
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optimization.  Aa  a result,  this  phase  can  become  quite  costly  to 

Implement. 

Thus,  the  designer  had  to  ohoose  between  achieving  a limited  machine 
Independence  at  the  cost  of  poor  optimization  or  producing  optimized  code  and 
Investing  a substantial  effort  for  each  new  target  machine. 

In  an  effort  to  accommodate  a wider  class  of  machines  than  encompassed 
by  a single  AM,  some  researchers  [Bunza,  Wick]  have  used  a more  general 
machine-description  facility  such  as  that  provided  by  ISP  [Bell].  An  ISP  description 
provides  a low-level  (l.e.,  register  transfer),  highly  detailed  description  of  the 
target  machine  which  is  amenable  to  mechanical  Interpretation  to  simulate  the 
described  processor.  If  an  ISP  description  of  source  language  operations  Is  also 
available,  a sophisticated  code  generator  would  have  sufficient  information  to 
complete  a translation.  Despite  the  success  of  ISP  In  describing  processors 
[Barbacci],  It  is  not  really  suitable  for  describing  the  semantics  of  a high-level 
language:  the  level  of  detail  required  by  ISP  would  require  complex  descriptions  for 
many  of  the  operators  and  data  types  of  the  language.  In  addition,  reducing  the 
semantics  of  the  target  machine  and  source  language  to  their  lowest  common 
denominator  results  In  the  loss  (or  obscuring)  of  Information  used  by  many 
optimization  strategies. 

The  Introduction  of  attlbuta  grammars  [Knuth,  Lewis]  has  coupled  recent 
research  with  the  formal  systems  developed  for  the  parsing  phase  of  compilation. 
In  an  attribute  grammar,  the  underlying  grammar  is  augmented  by  the  addition  of 
attributes  associated  with  the  nonterminal  symbols  of  the  parse.  These  attributes 
correspond  to  the  "meaning"  of  their  associated  symbol;  this  naturally  leads  to  two 
categories:  Inherited  and  synthesized  attributes.  Inherited  attributes  describe  the 
context  In  which  the  nonterminal  symbol  appears;  synthesized  attributes  describe 
those  properties  oV  utt  nonterminal  symbol  which  derive  from  Its  component  parts. 
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The  relationship  between  the  attributes  of  one  symbol  and  another  Is  specified  by 
"semantic  rules"  associated  with  each  production  defining  the  synthesized 
attributes  for  the  nonterminal  symbol  on  the  left-hand  side  of  the  production  and 
the  Inherited  attributes  for  the  nonterminal  symbols  on  the  right-hand  side  of  the 
production.  [Neel]  presents  several  production  systems  augmented  with  attributes 
that  describe  Information  commonly  collected  in  the  course  of  optimization  (block 
numbers,  whether  a statement  can  be  reached  during  execution,  etc.).  The 
principal  advantage  of  such  production  systems  Is  that  there  are  no  dependencies 
In  the  formalism  on  specific  language  or  machine  semantics  - attribute  grammars 
provide  a general  mechanism  for  accumulating  contextual  Information  during  the  first 
phase  of  compilation.  However,  optimizations  that  require  other  than  a local 
examination  of  context  are  hard  to  accommodate:  constructing  the  appropriate 
attributes  can  be  nontrivial  (cf.  lambda  calculus  example  In  [Knuth]).  Finally, 
except  In  trivial  cases,  translation  Into  a target  machine  program  (with  the 
attendant  optimizations)  still  requires  another  phase  - one  which  Is  highly  machine 
dependent. 

Attributes  have  been  adopted  by  Newcomer  In  his  work  on  generalizing  the 
optimization  strategies  employed  by  the  BLISS/ 1 1 compiler  [Newcomer],  In 
performing  the  expansion  into  PDP-11  code,  this  compiler  depends  heavily  on  tables 
which  contain  hand-compiled  Information  on  the  best  choices  for  each  expansion. 
Newcomer  attempts  to  automate  the  production  of  these  tables  by  examining  a 
description  of  the  target  machine.  He  uses  a GPS-like  search  technique  based  on 
a difference  operator  to  exhaustively  search  possible  Instruction  sequences  - from 
this  search  (guided  by  a preferred  attribute  set  Initially  specified  In  the  machine 
description)  he  collects  the  Information  needed  to  construct  the  tables.  The 
machine  description  is  a set  of  context-sensitive  transformations  where  the 
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appropriate  context  Is  established  through  the  use  of  attributes.  Although  the 
results  of  this  work  do  not  establish  the  viability  of  automatically  constructing  a 
compiler  in  this  manner,  the  notion  of  context-sensitive  transformations  as  the  basis 
of  a machine  description  Is  a valuable  contribution  to  the  IL/ML  system. 

Perhaps  the  most  successful  attempt  to  date  at  constructing  a module;  code 
generation  scheme  Incorporating  a fairly  complete  optimization  repertoire  Is  the 
General  Purpose  Optimizing  (GPO)  compiler  developed  at  IBM  [Harrison],  The 
structure  of  the  GPO  compiler  is  similar  to  that  proposed  by  this  thesis:  there  Is  an 
Intermediate  language  schema  used  as  the  internal  representation,  a set  of  defining 
procedures  that  serve  as  the  basis  for  translating/expanding  programs  Into 
pseudo-machine  language,  and  a program  which  modifies  the  Internal  representation 
as  optimizations  and  expansions  are  applied.  The  expansions  and  optimizations  are 
Iterated  until  the  translation  Is  complete;  a final  phase  translates  the  resultant 
program  Into  machine  language,  performing  register  assignments,  etc.  The  GPO 
compiler  is  oriented  towards  PL/l-like  programs  - the  primitives  provided  In  the 
Intermediate  language  directly  support  block  structure,  PL/I  pointer  semantics,  etc. 
The  set  of  defining  procedures  allow  tailoring  of  code  dependent  on  attributes  of 
the  operands.  The  main  differences  between  the  GPO  compiler  and  IL/ML  are 

a the  lack  of  sophisticated  name  management  (e.g.,  overlaying,  aliasing) 
on  the  part  of  the  GPO  compiler. 

a the  syntax  of  defining  procedures  of  the  GPO  compiler  are  best 
suited  for  PL/l-like  programs. 

a there  Is  no  notion  of  combining  adjacent  statements  into  a single 
operation  (as  in  peephole  optimization).  Although  Harrison  talks  of 
compiling  past  the  machine  Interface,  optimizations  take  place  on  a 
statement-by-statement  basis  (i.e.,  there  Is  no  general  pattern 
matching  facility). 

a In  the  GPO  compiler,  attributes  are  treated  Nke  any  other  variable  - 
optimizations  such  ss  constant  propagation  are  relied  upon  to  make 
the  attribute  Information  available  throughout  the  program.  IL/ML 
provldea  a separate  semantics  for  attributes  thereby  eliminating 
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certain  situations  where  the  optimizations  would  not  be  able  to 
unravel  a complicated  sequence  of  statements. 

The  complexity  of  the  GPO  compiler  is  greatly  reduced  from  that  of  cirrent  PL/l 

optimizing  compilers.  [Carter]  has  hand-simulated  the  expansion  of  tast  cases 

using  a set  of  simple  defining  procedures  for  the  substring  operator  of  PL/l, 

producing  code  which  equals  or  betters  that  of  the  IBM  optimizing  compler  (which 

Includes  some  8000  statements  to  treat  special  cases  of  substring).  The  Inclusion 

of  more  sophisticated  optimizations  in  the  processor  (cf.  [Schatz])  should  further 

Improve  these  statistics.  Encouragingly,  many  of  these  results  seem  applicable  to 

the  formalism  proposed  in  this  thesis  - the  increased  generality  of  IL/ML  should  not 

reduce  its  performance  in  this  area. 

$1.6  Outline  of  remaining  chapters 

Chapter  2 is  a detailed  description  of  the  Intermediate  language  IL:  the 
syntax  of  IL  Is  defined  and  the  representation  of  data  Is  discussed.  The  semantics 
of  each  IL  construct  is  described  and  related  to  the  needs  of  ML  and  the 
metainterpreter.  The  chapter  concludes  with  a brief  Introduction  to  the  compile- 
time calculation  of  values. 

Chapter  3 discusses  the  construction  of  a transformation  from  ML  templates 
that  specify  its  context  and  effect.  The  syntax  of  a template  (description  of  an  IL 
program  fragment)  is  described  emphasising  the  utility  of  wild  cards  and  built-in 
functions.  Rules  for  applying  the  transformation  and  updating  the  IL  program  are 
given.  The  final  section  describes  a few  sample  transformations. 

Chapter  4 presents  a set  of  sample  transformations  and  simulates  their 
application  by  the  metainterpreter  to  a sample  IL  program.  This  detailed  example  is 
aimed  at  demonstrating  the  ease  of  constructing  a transformation  catalogue  and 
feasibility  of  performing  code  generation  using  the  IL/ML  system. 
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The  final  chapter  briefly  diacussns  the  metainterpreter  and  the  facilities  it 
should  provide  then  summarizes  the  results  of  this  work  and  suggests  directions  for 
further  research. 
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CHAPTER  TWO 


$2.1  The  intermediate  language:  IL 

The  intermediate  language  described  In  this  chapter  serves  as  foundation 
for  a specification  constructed  as  outlined  in  $1 .3.  IL  supports  a skeletal  semantics 
common  to  ail  programs  from  source  to  machine  language;  this  includes  primitives  to 
describe  the  flow  of  control  and  the  managing  of  names  and  values  within  an  IL 
program.  In  addition,  IL  includes  a mechanism  for  accumulating  information  on 
particular  operations  and  storage  cells  for  later  use  by  the  transformation 
catalogue  and  the  metainterpreter.  The  remainder  of  the  semantics  of  an  IL 
program  (e.g.,  the  meaning  of  operations)  reside  in  the  transformation  catalogue  and 
are  made  available  when  these  transformations  are  applied  by  the  metainterpreter. 
By  relegating  the  language  and  machine  dependence  to  the  transformation 
catalogue  and  providing  a general  syntactic  mechanism  for  accumulating  information, 
IL  becomes  a suitable  Intermediate  language  for  the  entire  translation  process.  In 
order  to  allow  common  code  generation  operations  (flow  analysis,  compile-time 
calculation  of  values)  to  be  subsumed  by  the  metainterpreter,  separate  fields  are 
provided  in  each  IL  statement  for  the  Information  required  by  the  metainterpreter  in 
performing  Its  analysis. 

Although  IL  in  its  moot  general  form  has  a rather  skeletal  semantics  and  Is  a 
suitable  Intermediate  language  for  a wide  variety  of  source  languages,  certain 
conventions  are  established  below  for  use  In  examples  In  later  sections.  Most  of 
these  conventions  wars  Inspired  by  conventional  sequential,  algebraic  languages 
such  as  ALGOL,  BLISS,  or  even  CLU  that  are  amenable  to  efficient  interpretation  by 
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conventional  machine  architectures  (l.e.,  those  traditionally  thought  of  as  complied 
languages).  These  conventions  will  be  Inappropriate  in  part  for  compiled  languages 
that  are  not  related  to  ALGOL  (e.g.,  LISP);  In  many  cases  these  can  be  easily 
accommodated  by  relatively  simple  changes.  No  direct  attention  has  been  paid  to 
the  special  problems  associated  with  the  translation  of  those  languages  whose 
control  structure  differs  substantially  from  that  of  ALGOL  (e.g.,  SNOBOL,  DYNAMO, 
SIMULA,  etc.);  this  omission  reflects  the  bias  of  this  research  towards  the 
specification  of  conventional  code  generators.  Hopefully,  further  work  will  fill  this 
gap. 

The  most  common  form  of  Intermediate  representation  is  a flow  graph  of 
basic  blocks  where  each  basic  block  Is  described  by  a directed  acyclic  graph  or 
dag  (see,  for  example,  Chapter  12  of  [Aho77b]).  IL  Is  a linearization  of  this 
graphic  representation  with  several  additional  restrictions  to  allow  easy  modeling  of 
conventional  languages.  An  IL  statement  may  specify  one  of  two  actions:  the 
conditional  transfer  of  control  to  another  statement  (these  correspond  to  the  arcs 
of  the  flow  graph);  or  the  application  of  an  operator  to  Its  operands  (these 
correspond  to  the  interior  nodes  of  a dag),  optionally  saving  the  result  in  a named 
cell.  Similarly,  an  IL  statement  may  have  one  of  two  effects:  transfer  of  control  or 
the  change  In  the  value  of  one  or  more  cells.  As  we  will  see  below,  It  Is  easy  to 
determine  the  exact  effect  of  a statement  from  Its  syntactic  form;  targets  of 
transfers  of  control  and  the  set  of  cells  changed  by  a statement  (Its  kill  set ) are 
syntactically  distinguishable  from  other  portions  of  an  IL  statement. 

As  mentioned  above,  IL  provides  a schematic  representation  which  is  flexible 
enough  to  be  used  for  programs  varying  In  level  from  source  to  machine  language. 
To  encompass  such  a variety  of  programs,  IL  could  not  (and  does  not)  have  much  in 
the  way  of  built-in  semantics.  The  following  list  summarizes  the  primitive  concepts 
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Of  IL: 


• conditional  transfer  of  control  to  another  IL  statement.  In  the 
absence  of  a transfer  of  control,  execution  proceeds  sequentially 
through  the  IL  program. 

e application  of  an  operator  to  Its  operands.  There  are  no  bullt-ln 
operations  supported  by  IL  - the  designer  must  ensure  that  each 
operator  can  be  Interpreted  by  the  target  machine  or  further 
expanded  in  the  transformation  catalogue. 

• value  storage  provided  by  named  cells.  The  scope  of  a cell  name  and 
the  extent  of  its  storage  cover  the  entire  IL  program.  Note  that 
there  Is  no  distinction  betwe*  n program  variables  and  compiler 
temporaries  - all  requirements  for  value  storage  must  be  met  by 
using  cells.  Cell  references  have  an  Ivalue/rvalue  semantics  similar 
to  BCPL  or  BLISS.  The  name  of  a cell  serves  as  its  lvalue;  applying 
the  contents  operator  to  the  lvalue  of  a cell  (l.e.,  <lvalue> ) yields  the 
rvalue  of  that  cell.  Aggregate  data  such  as  arrays  or  structures  may 
be  modeled  by  structuring  the  lvalue  and  rvalue  of  a cell. 

a attributes  for  both  lvalues  and  rvalues  provide  a syntactic  mechanism 
for  accumulating  "declared11  information  that  is  unaffected  by 
subsequent  IL  operations.  A third  type  of  attribute  provides  the 
same  capability  for  each  statement  in  an  IL  program. 

• literals  fill  the  dual  role  of  reserved  words  (operators,  attribute 
names,  etc.)  and  constant  rvalues  (numbers,  character  strings,  etc.). 

The  meaning  of  a literal  is  "self-contained,"  one  need  go  no  further 
than  the  statement  In  which  it  appears  to  establish  its  meaning.  Note 
that  there  is  no  such  thing  as  a literal  lvalue,  i.e.,  an  lvalue  whose 
meaning  can  be  established  Independently  of  the  context  In  which  It 
appears  - thus  It  Is  not  legal  to  apply  the  contents  operator  to  a 
literal. 

The  following  sections  describe  each  of  these  areas  In  more  detail,  discussing  how 
popular  concepts  such  as  block  structure,  data  types,  etc.  are  handled  by  IL. 


§2.2  Data  in  IL 

All  data  storage  In  IL  Is  provided  by  named  cells  - program  variables, 
intermediate  results,  etc.  are  represented  In  an  IL  program  by  a cell.  Each  cell  has 
three  components: 

(1)  an  lvalue  (name)  which  unambiguously  Identifies  the  cell.  The  scope 
of  the  lvalue  covers  the  entire  IL  program.  An  lvalue  can  be 
structured  for  modeling  arrays,  structures,  etc. 
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(2)  an  rvalue  (written  <lvalue>)  which  la  modified  whenever  the  cell 
named  lvalue  la  uaed  to  hold  the  reault  of  an  operation.  Any  quantity 
aaaoclated  with  the  cell  that  can  be  modified  by  an  IL  operation  la 
considered  to  be  part  of  the  rvalue;  If  more  than  one  such  quantity 
exists,  both  the  rvalue  and  the  lvalue  muat  be  structured. 

(3)  a set  of  attributes  associated  with  either  the  lvalue  or  rvalue. 
Attributes  are  used  for  declarative  information  that,  once  established, 
is  unaffected  by  subsequent  IL  operations  - attributes  are  sort  of  a 
manifest  rvalue. 

Note  that  no  automatic  translation  Is  provided  by  the  metainterpreter  for  cells;  the 
designer  is  responsible  for  realizing  each  cell  utilized  in  the  IL  program  (by 
incorporating  appropriate  transformations  In  the  transformation  catalogue).  This 
may  include  allocating  main  storage  (for  program  variables),  assigning  registers  (for 
short-lived  intermediate  results),  or  subsuming  them  completely  (for  Intermediate 
results  computed  at  compile  time  or  internally  by  the  target  machine  - e.g.,  indexed 
addressing). 

Although  an  lvalue  unambiguously  identifies  a cell,  it  is  not  necessarily 
unique.  A given  cell  may  come  to  have  more  than  one  name  through  redundant 
expression  elimination  or  the  ALIAS  pseudo-operation  (see  $2.3.3).  From  then  on 
either  name  may  be  used  Interchangeably.  The  ALIAS  pseudo-operation  may  also  be 
used  to  Implement  the  overlaying  of  storage,  an  operation  provided  in  many  source 
languages  by  allowing  the  equlvalenclng  of  names.  Unlike  FORTRAN,  however,  each 
alias  must  be  made  explicitly  - this  Is  explored  further  In  $2.2.2.  Note  that  an 
lvalue  may  be  used  as  an  operand  and  that,  as  an  operand,  It  will  require 
declaration  of  attributes  similar  to  those  for  an  rvalue  (type,  length,  value,  etc.)  - 
care  must  be  taken  so  as  not  to  confuse  lvalue  attributes  with  rvalue  attributes 
and  vice  versa. 

There  is  no  separate  provision  for  the  scoping  of  lvalues  (block  structure). 
Through  a declaration  of  a variable  of  the  same  name  In  an  Inner  block,  scoping 
allows  shielding  of  a cell  from  use  Inside  that  block.  In  practice,  however, 
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procedure  calls  and  pointers  allow  access  to  cells  which  are  not  directly 
accessible  as  operands.  Thus  the  original  cell  cannot  be  "forgotten"  completely 
while  processing  the  Inner  block:  a mechanism  must  be  provided  for  referencing 
both  the  new  cell  and  shielded  cell  when  describing  the  effect  of  computations 
within  the  Inner  block.  The  other  information  provided  by  scope  rules  - lifetime 
Information  - is  more  accurately  determined  by  live  variable  analysis  performed  by 
the  metainterpreter.  The  additional  cells  provided  for  by  scope  rules  can  be 
created  by  choosing  different  cell  names  for  each  new  declaration  of  the  variable 
(perhaps  by  suffixing  the  linear  block  number  to  the  variable  name). 

IL  does  not  directly  support  data  types  (not  even  bit  strings!):  rvalues  are 
simply  objects.  If  the  source  language  has  declared  types,  these  may  be 
Incorporated  as  attributes  of  the  rvalue  (for  tagged  data  types  the  type 
Information  Is  another  component  of  the  rvalue).  Transformations  can  utilize  these 
attributes  to  tailor  the  generated  code  (see  Figure  2.2).  Similar  conventions  suffice 
for  other  properties  of  rvalues:  their  size,  precision,  etc.  In  theory,  data  types 
provide  additional  information  in  strongly  typed  languages.  For  example,  assignment 
through  an  Integer  pointer  should  affect  only  cells  whose  rvalues  have  type  Integer. 
In  practice,  aliasing  (see  above),  lack  of  type  checking  in  computing  pointer  values, 
and  (legal)  Inconsistencies  between  actual  and  formal  procedure  parameters 
conspire  to  prevent  the  designer  from  taking  advantage  of  this  additional 
Information.  In  other  words,  just  because  the  pointer  has  been  declared  as  integer 
pointer  does  not  guarantee  that  it  points  to  only  cells  of  type  integer.  It  Is  worth 
noting  here  that  the  metainterpreter  does  know  about  certain  classes  of  objects, 
such  a..  numbers,  allowing  transformations  to  manipulate  certain  rvalues  at  compile 
time. 
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$2.2.1  Attributes 

Attributes  provide  a general  mechanism  for  associating  information  with 
components  (cells  and  statements)  of  an  IL  program.  Attributes  associated  with 
the  lvalue  or  rvalue  of  a cell  provide  Information  which  Is  unaffected  by  IL 
operations,  e.g.,  Its  type,  storage  class,  size,  etc.  This  Information  Is  Initially 
provided  by  the  first  phase  of  the  compiler  or  added  during  translation  by 
transformations  as  It  Is  "discovered."  Once  established,  cell  attributes  are 
available  from  any  point  In  the  IL  program  - dynamic  information  that  Is  context 
dependent  (e.g.,  which  register  contains  the  current  value  of  the  cell)  cannot  be 
stored  as  an  attribute^.  Attributes  are  the  work  horse  of  a specification:  they 
provide  a symbol  table  facility  for  each  declared  variable  and  intermediate  result, 
model  synthesized  and  Inherited  attributes  used  for  passing  contextual  information 
about  the  operation  tree,  and  soon  atf  Infinitum. 

Statement  attributes  allow  Information  not  relevant  to  the  result  cell  to  be 
associated  with  each  statement.  This  Includes  properties  of  the  operator  (e.g., 
commutativity,  size  of  a target  machine  Instruction),  effects  on  the  global  state  of 
the  Interpreter  (e.g.,  which  condition  codes  are  changed  by  a target  machine 
operator),  progress  made  in  translating  the  statement  (useful  for  communication 
between  a set  of  transformations),  etc.  By  incorporating  these  pieces  of 
Information  as  attributes,  transformations  can  tailor  the  IL  program  taking  Into 
consideration  machine-  and  language-dependent  features  without  building  machine 
and  language  dependencies  Into  the  metainterpreter. 


t Dynamic  Information  may  be  stored  as  part  of  the  rvalue  of  a cell;  In  many  cases 
complle-tlme  computation  of  rvalues  will  propagste  this  Information  as  effectively  as 
If  It  were  an  attribute.  Moreover,  much  of  thle  type  of  Information  Is  used  for 
optimizations  which  are  already  Incorporated  in  the  metainterpreter. 
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Attributes  are  referenced  in  an  IL  program  as  follows: 


Hattrlbute_name"  for  statement  attributes; 

"lva/ue:attrlbute_name"  for  lvalue  attributes; 
"<lvalue>\Bttrlbute_name"  for  rvalue  attributes. 

Each  attribute  has  a value  (always  a literal)  established  In  some  IL  statement  by 
Including  an  assignment  to  the  attribute  name  In  the  attribute  field  of  that 
statement.  For  example,  the  following  IL  program  statement  Illustrates  the 
attributes  which  might  be  associated  with  the  declaration  of  a real  variable  "Z"  in 
a PASCAL  program: 


Label 

Operator  Operands 

Attributes 

Z 

declaration 

Z:typesunslgnedJnteger  Z:slze=2 
Z:level-2  Z:offset=14 
<Z>:type=real  <Z>:size=8 

The  first  line  indicates  that  the  address  (lvalue)  of  Z is  a two  byte  unsigned 
Integer  - this  information  will  be  needed  for  type  checking  performed  by  some 
transformation  If  Z enters  into  a pointer  calculation.  The  second  line  gives  the 
lexical  level  and  stack  frame  offset^  assigned  to  Z (either  by  the  first  phase  of  the 
compiler  or  a transformation  applied  earlier);  a transformation  could  be  Included  In 
the  transformation  catalogue  to  compute  the  actual  address  of  Z from  this 
Information.  Finally,  the  third  line  Indicates  that  the  value  of  Z occupies  8 bytes 
and  has  type  real.  Note  that  the  "declaration"  operator  has  no  special  significance 
In  IL;  any  semantics  associated  with  this  operator  (e.g.,  allocation  of  storage  or  the 
Initialization  of  Z's  rvalue)  will  be  captured  In  the  transformation  catalogue.  The 
same  is  true  for  each  of  the  attributes  described  In  this  paragraph:  In  IL,  their 
values  are  simply  literals  - the  Interpretation  ascribed  to  them  in  the  explanation 


t These  ware  arbitrarily  chosen  to  be  lvalue  attributes:  general  attributes  of  a cell 
may  be  associated  with  either  the  lvalue  or  rvalue  - a convention  Is  chosen  here 
so  that  the  transformations  "know  where  to  look"  for  the  Information. 
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reflects  the  role  they  pley  In  transformations  applied  by  the  metainterpreter. 

$2.2.2  Structuring  of  call  names  and  values 

The  ability  to  structure  Ivslues  (and  their  corresponding  rvslues)  simplifies 
the  modeling  of  aggregate  data  and  operations  which  affect  one  or  more 
components.  Each  component  is,  In  efTect,  a separate  lvalue;  Its  type,  size,  and 
other  attributes  can  be  maintained  separately  from  those  of  other  components.  It 
Is  also  possible  to  perform  operations  on  the  aggregate  data  as  a whole,  changing 
all  components  in  one  operation.  A component's  lvalue  is  constructed  by  appending 
the  appropriate  selector  to  the  lvalue  of  the  aggregate,  like  so: 
aggregate_name.selector.  For  example,  If  A were  an  array  dimensioned  from  1 to 
10  then 

rvalue  refers  to 

<A>  the  entire  array 

<A>.2  A[2],  the  second  component  of  A 

<A>.<»  A[l],  the  Ith  component  of  A 

<A>."  all  components  of  A (A.1  through  A.  10) 

Note  that  <aggregate_name.selector>  is  equivalent  to  <aggregate_name>. selector  - 
either  form  may  be  used  interchangeably.  In  the  last  line,  was  Introduced  as  a 
convenient  abbreviation  for  "all  possible  component  names."  Of  course,  ,,,,,,  is 
never  actually  expanded  but  rather  serves  as  a wild  card  when  resolving  attribute 
references  to  components  of  an  aggregate  cell.  For  example,  <A>."  would  be  used 
when  referring  collectively  to  elements  of  the  array,  as  when  declaring  the  type  of 
the  elements  (assuming  A is  homogeneous).  Thus,  If  a program  contained  the 
definition  <A>.*:type*boolean  then  the  attribute  reference  <A>.3:type  could  be 
resolved  to  "boolean."  <A>."  used  as  the  prefix  of  an  attribute  reference  Is  not 
equivalent  to  <A>:  attributes  for  an  aggregate  are  maintained  separately  from 
those  of  Its  components.  The  following  IL  statement  Illustrates  the  attributes  which 
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might  be  associated  with  a declaration  of  the  above  array: 


Label 

Operator  Operands 

Attributes 

1 

declaration 

A:typesunsigned_lnteger  A:size=2 

A:dlm«naions=1  A:ubound=10 

A:lbound=1  A:lbound:type=lnteger  A:lbound:size=2 
<A>:type=array  <A>:size=10 
<A>.":type*boolean  <A>.*:slze=1 

Note  that  the  example  specifies  that  the  rvalue  of  A is  an  array  10  bytes  long  and 
that  the  lvalue  of  A is  a 2-byte  unsigned  Integer  (just  like  any  other  address!). 
The  third  line  Is  included  since  A:lbound  is  likely  to  be  used  as  an  operand  In 
subscript  calculations  and  therefore  needs  the  appropriate  attributes.  The  final  line 
indicates  the  type  and  size  of  the  components  of  the  array.  In  choosing  the 
attributes  to  be  included  in  this  array  declaration,  every  effort  has  been  made  to 
ensure  that  each  quantity  which  might  appear  as  an  operand  in  subsequent 
operations  has  the  required  attributes.  This  eliminates  the  need  for  any  special 
casing  - a multiply  operation  performed  during  a subscript  calculation  receives  the 
same  treatment  as  any  multiply  operation. 

In  many  cases  the  """  notation  Is  more  powerful  than  the  corresponding 
expansion.  For  example,  consider  the  declaration  given  above  and  the  attribute 
reference  <A>.<l>:type  (the  type  of  the  Ith  component  of  A).  The  last  line  of  the 
declaration  indicates  that  the  type  of  any  component  is  "boolean"  and  so 
<A>.<l>:type  can  be  resolved  to  "boolean"  without  further  ado.  If,  on  the  other 
hand,  separate  type  definitions  had  been  provided  for  each  component  - i.e., 
<A>.1  :type*boolean,  etc.  - resolution  of  <A>.<l>:type  could  not  proceed  without 
more  knowledge  of  <l>  (the  value  of  the  subscript).  Even  though  bounds  checking 
may  be  desirable,  It  is  better  accomplished  explicitly  at  run  time  rather  than 
Implicitly  during  compile-tlme  type  checking.  Another  solution  would  be  to  endow 
the  metainterpreter  with  special  knowledge  concerning  attributes  of  array 
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subscripts,  but  this  lesds  to  undesirable  language  dependencies  In  the 
metainterpreter.  All  In  all,  the  """  notation  comes  much  closer  to  the  semantics 
common  to  most  aggregate  data  and  leads  to  a simple  mechanization  of  attribute 
resolution. 

Operations  which  affect  the  rvalue  of  an  aggregate  cell  (e.g.,  an  array 
assignment  to  <A>)  are  understood  to  change  the  rvalues  of  the  components  (e.g., 
<A>.1,  <A>.2,  ...,  <A>.1 0).  The  converse  is  also  true:  a change  in  a component’s 
rvalue  changes  the  rvalue  of  the  aggregate.  Both  cases  are  based  on  the  premise 
that  the  rvalue  of  an  aggregate  Is  the  "sum"  of  Its  components  - i.e.,  that  the 
rvalue  of  an  aggregate  Is  not  maintained  separately  from  the  rvalues  of  its 
components.  Thus  <A>  Is  equivalent  to  <A>."  (when  speaking  of  rvalues  - this 
differs  trum  the  conclusion  reached  above  for  the  managing  of  attributes).  The 
effect  of  this  reasoning  (see  discussion  In  $2.3.1  on  augmentation  of  kill  sets) 
coincides  with  common  practice:  a change  In  <A>.3  should  invalidate  any  temporary 
copies  of  the  whole  array  (<A»  but  should  not  affect  temporary  copies  of  other 
components  (e.g.,  <A>.7);  on  the  other  hand,  changes  in  the  whole  array  should 
Invalidate  temporary  copies  of  any  component. 

As  a Anal  example  of  a structured  cell,  consider  the  following  series  of  IL 
statements  (see  $2.3.3  for  a detailed  description  of  the  ALIAS  pseudo-operation): 


Label 

Operator 

Attributes 

H 

declaration 

X:typeaunslgnedJnteger  X:size=2 
<X>:type*long  <X>:size-4 

II 

ALIAS 

X.1 

htypesunsignedjnteger  l:size-2 
<l>:type=integer  <l>:slze*2 

ALIAS 

X.2 

J:type>unslgned_lnteger  J:size=2 
<J>:type=integer  <J>:slze=2 

In  this  example,  the  rvalues  of  I and  J overlay  the  rvalue  of  X (the  designer  has 
the  responsibility  for  making  the  storage  allocated  for  I and  J overlay  the  storage 
for  X In  the  final  translation  by  adding  appropriate  transformations  to  the 
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catalogue).  Note  that  although  X Is  not  explicitly  declared  to  have  any 
components,  aliasing  I and  J to  X.1  and  X.2  has  caused  them  to  become 
components  of  X.  Thus,  using  the  reasoning  of  the  preceding  paragraph: 

(1)  changes  to  the  rvalue  of  X Invalidate  the  rvalues  of  I and  J; 

(2)  changes  to  the  rvalue  of  I Invalidates  the  rvalue  of  X,  but  does  not 
affect  the  rvalue  of  J;  and 

(3)  changes  to  the  rvalue  of  J Invalidates  the  rvalue  of  X,  but  does  not 
affect  the  rvalue  of  I. 

The  final  two  conditions  show  that  I and  J are  understood  to  be  disjoint.  These 
three  conditions  are  just  the  semantics  one  associates  with  overlayed  storage^. 

§2.3  The  syntax  of  IL 

An  IL  program  is  a sequence  of  statements  made  up  of  tokens  classed  as 
literals,  lvalues  (the  name  of  a cell),  or  rvalues  (the  application  of  the  contents 
operator  to  an  lvalue).  Depending  on  where  a token  appears  In  an  IL  statement,  it 
Is  further  classified  as  a label,  operator,  operand,  or  attribute.  Label  tokens  must 
be  lvalues;  operator  and  attribute  tokens  are  always  literals;  operand  tokens  may 
be  any  flavor.  Beyond  the  semantics  associated  with  these  four  classes  of  tokens, 
IL  provides  no  further  Interpretation  of  ordinary  tokens.  In  this  sense,  IL  Is  similar 
to  a BNF:  neither  provides  any  Interpretation  of  the  symbols  of  the  language. 
Special  tokens  are  provided  to  Indicate  transfers  of  control  and  their  corresponding 
targets  within  an  IL  program.  These  tokens  are  used  In  data  flow  analysis  and  are 
seldom  referenced  directly  by  the  user.  An  IL  statement  has  the  following  form: 


t No  provision  has  been  made  to  show  how  to  compute  new  values  of  I and  J from 
a new  value  of  X (and  vice  versa).  The  details  of  this  computation  depend  on 
storage  allocation  and  machine  representations  and  so  should  be  relegated  to  the 
transformation  catalogue.  Such  transformations  can  be  generated  at  complle-time 
from  the  ALIAS  statement  through  the  use  of  transformation  macros  (see  §3.?). 
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where  the  components  are  described  below. 

label  This  field  names  the  cells  whose  rvalues  might  be  changed  by  this 

statement.  Two  labels,  ■*  and  e,  have  a special  meaning  to  the 
system  (see  Section  2.3). 

operator  This  field  indicates  the  operation  performed  by  this  statement. 

operand...  Zero  or  more  operands  used  as  arguments  to  the  preceding  operation. 

attribute...  A set  of  zero  or  more  "name*valuen  pairs  further  describing  the 
context  and  semantics  of  the  statement. 

Figure  2.1  shows  the  Initial  IL  representation  of  the  following  program: 
integer  X,Y,Z; 

If  X>Y  then  { X=2;  Y=3  > else  { X=3;  Y=2  }; 

Z « X+Yj 

There  is  no  single  IL  representation  for  a given  program;  e.g.,  one  could  eliminate 
the  definition  of  Cl  and  C2  entirely  from  Figure  2.1  and  use  the  literals  n2"  and 
H3H  directly.  Choices  as  to  the  number  of  levels  of  Indirection,  etc.  are  not 
dictated  by  IL  and  can  be  made  on  the  basis  of  compatibility  with  the 
transformation  catalogue,  appropriateness  for  the  target  machine,  etc.  Note  that  in 
Figure  2.1  attributes  have  only  been  given  for  the  declaration  portion  of  the 
program  - the  remainder  will  be  filled  In  by  the  metainterpreter  as  It  applies 
transformations.  The  initial  attributes  are  similar  to  those  that  might  be  provided  by 
the  first  phase  of  the  compiler.  Attributes  are  described  in  more  detail  In  $2.2.1. 

In  the  description  which  follows,  it  will  be  useful  characterize  tokens  as 
either  literals  or  references  (either  an  lvalue  or  rvalue).  By  way  of  example, 
consider  the  foliowing  two  lines  from  Figure  2.2: 
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Operator 

Operands 

Attributes 

declaration 

X:type=integer  X:slze=2 
<X>:type*=lnteger  <X>:slze=2 

declaration 

Y:type=integer  Y:size=2 
<Y>:type=lnteger  <Y>:slze=2 

declaration 

Z:type=lgteger  Z:slze=2 
<Z>:type=lnteger  <Z>:size=2 

constant 

i«2» 

<C1  >:type=integer 

constant 

"3" 

<C2>:type=integer 

greater.,  than 

<X>  <Y> 

if.goto 

<T1  > L2  LI 

label 

LI 

store 

<C2> 

store 

<C1> 

goto 

L3 

j 

label 

L2 

store 

<cr> 

store 

<C2> 

label 

L3 

add 

<X>  <Y> 

store 

<T2> 

Figure  2.1:  Initial  IL  representation 


Label 

Operator 

Operands 

T100 

equal 

<X>:type  " Integer " 

T1 

add 

<X>  <Y> 

Attributes 


The  italicized  tokens  are  literals;  the  rest,  references.  In  IL,  literals  are  nothing 
more  than  character  strings  - Interpretation  of  these  strings  Is  provided  by  the 
transformation  catalogue  and  the  metainterpreter.  References  "refer"  to  values 
established  by  other  statements  - they  provide  a level  of  indirection.  The  principal 
difference  between  literals  and  references  Is  that  the  meaning  of  a literal  can  be 
established  at  compile  time  whereas  references  often  refer  to  values  that  are  not 
known  until  execution  time.  Literals  are  of  central  Importance  during  optimization 
since  their  fixed  semantics  provide  opportunities  for  compile  time  evaluation  of 
operations.  Some  references  (e.g.,  <X>:type)  may,  depending  on  the  context  in 
which  they  appear,  refer  to  literals;  In  these  cases  It  Is  advantageous  to  remove 
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the  unnecessary  level  of  Indirection  at  compile  time.  For  those  references  that 
cannot  be  resolved  Into  literals  at  compile  time  (e.g.,  <X>),  It  will  be  necessary  to 
produce  code  which  actually  performs  the  Indirection  specified  in  the  IL  program 
(e.g.,  by  performing  a fetch  from  the  storage  location  used  to  hold  the  desired 
value). 

$2.3.1  The  label  field 

The  label  field  of  an  IL  statement  lists  the  cells  which  are  affected  by 

execution  of  that  statement.  A statement  may  affect  a cell  In  two  ways: 

a cell  is  killed  by  a statement  if  execution  of  the  statement  might 
cause  the  rvalue  of  the  cell  to  change;  the  set  of  killed  cells  Is 
called  the  kill  set. 

a cell  is  defined  by  a statement  if  execution  of  the  statement  always 
changes  the  rvalue  of  the  cell;  the  set  of  defined  cells  is  called  the 
defined  set  of  the  statement.  Note  that  the  defined  set  c the  kill  set 
for  any  statement. 

When  a cell  Is  killed,  Its  rvalue  can  no  longer  be  used  for  calculating  common 
subexpressions  (assuming  that  the  cell  had  not  been  killed  previously).  If  a cell  is 
defined  by  a statement,  It  will  always  contain  the  value  calculated  by  the 
statement  after  the  statement’s  execution.  Therefore,  if  a statement  executed 
subsequently  is  Identified  as  performing  the  same  computation,  it  can  be  replaced 
by  a reference  to  the  defined  cell.  Moreover,  If  the  defined  value  is  a literal, 
subsequent  references  to  the  rvalue  of  the  defined  cell  can  be  resolved  to  that 
literal.  By  convention,  the  lvalue  of  each  affected  cell  is  listed  In  the  label  field; 
the  Implicit  contents  operator  Is  omitted  for  the  sake  of  brevity.  The  label  field  is 
used  by  the  metainterpreter  In  two  important  optimizations:  redundant  computation 
elimination  and  use-definition  chaining  (compile-time  evaluation  of  statements). 

With  one  exception,  the  kill  set  provides  all  the  Information  needed  to 
perform  these  optimizations.  This  suggests  two  formats  for  the  label  field:  "K"  and 
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"K,On  where  K Is  the  kill  set  of  the  statement  and  D the  corresponding  defined  set 
(D  £ K).  When  the  abbreviated  first  format  is  used,  D is  calculated  as  follows: 

case  7.  If  K is  empty  (|K|  = 0)  then  D^f 

case  2.  if  K has  a single  element  (|K|  = 1 ) then  D>K. 

case  3.  If  |K|  > 1 then 

case  4.  If  K * {"}  then  D‘f 

Considering  only  statements  that  affect  at  most  one  cell  (all  the  statements  In 

Figure  2.1  fall  Into  this  category),  there  is  a natural  interpretation  for  each  of  the 

above  cases.  Statements  affecting  no  cells  (e.g.,  transfers  of  control)  are  covered 

by  case  1.  Statements  whose  operators  have  an  applicative  semantics  (add, 

multiply,  etc.)  fall  under  case  2;  the  single  element  of  the  kill  set  is  the  lvalue  of 

the  cell  where  the  result  is  stored.  The  specified  cell  is  always  changed  by 

executing  the  statement,  so  D = K.  This  is  also  the  case  for  assignment 

statements  which  always  change  the  same  cell  (i.e.,  they  do  not  compute  its 

lvalue)  - In  these  statements  the  label  Is  essentially  another  operand.  Case  3 

covers  assignment  statements  that  compute  the  lvalue  of  the  cell  In  which  the 

result  Is  to  be  placed,  e.g.,  assignments  through  pointers  or  to  array  elements  with 

non-constant  subscripts.  Here,  each  cell  in  K has  been  killed  (Its  previous  rvalue 

may  have  been  changed,  thus  It  can  no  longer  be  assumed  that  It  Is  available) 

however  no  cell  In  K has  been  defined  (no  single  cell  is  certain  to  have  been 

changed)  hence  D = #.  In  the  final  case,  a label  of  """  Indicates  that  all  cells 

might  be  affected  by  executing  the  statement.  For  essentially  the  same  reasons 

given  In  $2.2,  no  provision  has  been  made  for  specializing  """  by  specific  cell 

attributes  (e.g.,  type):  in  almost  every  language  there  exist  loopholes  which  make 

attribute  Information  unreliable^.  This  label  Is  used  when  the  statement  has 

t This  attribute  information  will  be  used  In  the  expansion  of  operations  In  the  IL 
program.  Despite  the  suspect  nature  of  attribute  values,  this  Is  the  semantics 
provided  by  many  languages  and  relied  upon  by  programmers  to  circumvent  certain 
language  restrictions.  However,  this  Information  cannot  be  used  as  a basis  for 
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unfathomable  alda-affacta,  for  axampla,  when  the  label  field  contains  too  complex 


an  expresalon  (e.g.,  deeply  nested  contents  operators)  - when  an  lvalue 
aubexpreaalon  has  become  unwleldly  It  la  always  legal  to  assume  Its  value  Is 
and  proceed  from  there.  This  overly  conservative  Interpretation  may  result  In 
missed  optimization  opportunities  but  naver  In  an  Incorrect  translation. 

Procedure  calls  have  the  potential  of  affecting  many  cells  and  so  do  not  fall 
Into  the  categories  discussed  above.  The  sequence  of  statements  which  form  the 
boc'y  of  the  procedure  may  kill  and  define  cells  - taken  In  the  aggregate  it  is 
possible  that  K = D * #.  In  addition,  procedures  that  return  e value  add  yet  another 
element  to  D (the  cell  containing  the  returned  value).  The  second  label  format, 
"K,D",  is  used  for  procedure  calls.  White  It  is  theoretically  possible  to  compute  the 
appropriate  label  by  examining  the  body  of  the  procedure,  this  calculation  quickly 
becomes  unwleldly.  A reasonable  alternative  is  to  assign  procedure  calls  the  label 
l,a,R"  where  R Is  the  lvalue  of  the  cell  In  which  the  returned  value  (If  any)  Is 
stored.  Thus  the  semantics  of  a procedure  call  Is  reduced  to  invalidating 
previously  calculated  values  for  all  cells  except  the  one  containing  the  return 
value. 

As  was  outlined  In  $2.2.2,  it  Is  occasionally  necessary  to  augment  the  kill  set 
of  a statement  to  account  for  the  semantics  of  aggregate  cells.  Although  the  size 
of  the  kill  set  may  be  Increased,  the  defined  set  calculated  above  remains 
unchanged  - essentially  no  new  cells  are  being  added  to  the  kill  set,  but  only  other 
lvalues  for  the  affected  rvalue(s).  The  objective  of  augmenting  the  kill  set  is  to 
explicitly  include  the  lvalue  of  every  cell  which  is  affected  by  the  statement;  this 
reduces  the  amount  of  computation  performed  by  the  metainterpreter  when  using 

optimizations,  as  Is  would  lead  to  Incorrectly  transformed  programs  - only  the 
programmer  Is  allowed  to  play  havoc  with  his  program! 
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The  following  algorithm  constructs  an  augmented  kill  set  K’  from  the  original 
kill  set  K.  K’  will  include  all  lvalues  ALIASed  to  lvalues  In  K as  well  as  the  lvalues 
of  aggregates  which  subsume  lvalues  In  K.  In  constructing  K’(  a distinction  Is  made 
between  an  aggregate  and  Its  components:  <f  an  aggregate  name  appears  in  K\  It 
refers  to  the  aggregate  treated  as  a single  value  (l.e.,  any  temporary  copies  of  the 
entire  aggregate  should  be  Invalidated);  If  temporary  copies  of  an  aggregate’s 
components  should  also  be  Invalidated,  the  notation  is  used.  For  example,  "A" 
would  invalidate  any  copies  of  the  array  A but  leave  its  components  unaffected; 
"A.*"  would  invalidate  any  components  (and  subcomponents,  etc.)  of  A.  The 
algorithm  is 


1.  Initially  K’  = K. 

2.  For  each  structured  lvalue  « In  K,  add  m.”  to  K’.  An  lvalue  Is 
structured  If  any  attributes  have  been  defined  for  any  lvalue  or 
rvalue  components  of  the  lvalue  or  If  ALIASes  have  been  made  to  any 
lvalue  components.  This  step  ensures  that  If  an  entire  aggregate 
value  was  in  the  original  kill  set,  all  of  its  components  will  also  be 
Invalidated  in  the  augmented  kill  set. 

3.  For  each  lvalue  • In  K’,  add  any  aliases  declared  for  « to  K\ 

4.  For  each  component  lvalue  ajt  In  K',  add  • to  K*.  The  Intent  here  is  to 
add  all  the  prefixes  for  each  component  lvalue,  e.g.,  If  A.  1.2.3  were 
an  element  of  K\  this  step  would  add  A.1.2,  A.1,  and  A to  K’. 

6.  Repeat  steps  3 and  4 until  no  more  additions  are  made  to  K’. 

The  final  result  for  K’  Is  the  augmented  kill  set  for  the  statement.  The  following 
series  of  examples  should  clarify  the  workings  of  the  algorithms.  For  purposes  of 


exhibition,  duplicate  lvalues  (e.g.,  X.*  and  X.1)  have  been  removed  from  the  kill 
sets.  The  examples  assume  the  declaration  given  In  examples  In  J2.2.2. 


original 
Mil  set  (K) 

{A.3  A.4) 


augmented 
kill  set  (1C) 
(A  A.-) 

{A.3  A.4  A) 
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3*. 


<A.«>  {A.«  A} 

<l>  <■  X.1  X) 

{X>  {X  X.«  I J) 

yr 

Note  that  the  augmented  kill  sets  agree  with  the  desiderata  outlined  In  $2.2.2. 

/ 

/ 

y 

$2.3.2  The  operator  and  operand  fields 

No  particular  semantics  is  attached  to  the  operator  field  of  a statement. 
The  meaning  of  an  operator  Is  established  by  transformations  which  expand  it  into 
other  IL  or  target  machine  operations.  A useful  analogy  for  an  IL  operator  is  a 
macro  - the  body  of  the  macro  defines  the  effect  of  an  operator  In  terms  of  other, 
usually  simpler,  operations.  If  the  effect  of  the  macro  can  be  accomplished  directly 
by  the  target  machine  no  further  refinement  of  the  operation  is  necessary;  the 
translation  of  the  statement  Is  complete.  Otherwise,  the  body  of  the  macro  (in  this 
case  a sequence  of  IL  operations)  should  be  substituted  for  the  operation,  making 
the  appropriate  substitutions  of  actual  operands  for  formal  parameters  of  the 
macro.  If  each  expansion  is  subject  to  later  optimization,  ft  is  possible  to  use 
general  definitions  for  each  macro  operation,  l.e.,  definitions  such  as  one  would  find 
In  an  interpreter.  Special  cases  that  hinge  on  particular  values  of  the  operands 
would  be  explicitly  tested  for  In  the  substituted  sequence;  later  optimization  would 
eliminate  those  operations  which  could  be  performed  at  compile  time.  For  example 
(see  Figure  2.2),  the  expansion  of  the  addition  operator  might  test  the  type  of  Its 
operands  and  then  perform  an  Integer  or  floating  point  addition  as  appropriate.  If 
the  type  of  the  operands  could  be  established  at  compile  time,  this  test  would  be 
subsumed  during  optimization.  Although  It  is  not  necessary,  use  of  general 
definitions  greatly  simplifies  the  top  level  of  a specification  as  there  will  be  only 
one  transformation  for  an  operation  rather  than  one  for  each  special  case. 
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Label 

Operator  Operands 

Attributes 

X 

Y 

T1 

declaration 

declaration 

plus  <X>  <Y> 

<X>  :type*lnteger 
<Y>:type*real 

Figure  2.2a:  Original  IL  program 


Label 

Operator 

Operands 

Attributes 

X 

declaration 

<X> : ty  pe =lnteger 

Y 

declaration 

<Y>:type=real 

T100 

equal 

<X>:type  "Integer" 

If.goto 

<T100>  LI  L4 

e 

label 

LI 

T101 

equal 

<Y>:type  "Integer" 

If.goto 

<T101>  L2  L3 

e 

label 

L2 

T1 

add 

<X>  <Y> 

goto 

L7 

e 

label 

L3 

T102 

float 

<X> 

• 

T1 

addf 

<T1 02>  <Y> 

-♦ 

goto 

L7 

e 

label 

L4 

T103 

equal 

<Y>:type  "real" 

-♦ 

lf_goto 

<T103>  L6  L6 

e 

label 

L6 

T1 

addf 

<X>  <Y> 

-♦ 

goto 

L7 

e 

label 

L6 

T104 

float 

<Y> 

T1 

addf 

<X>  <T104> 

e 

label 

L7 

Figure  2.2b:  IL  program  with  expanded  definition  of  plus 


Label 

Operator  Operanda 

Attributes 

X 

Y 

T102 

T1 

declaration 

declaration 

float  <X> 

addf  <T102>  <Y> 

<X>:type«lnteger 

<Y>:type*real 

Figure  2.2c:  "Optimized"  IL  program 
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Operands  serve  as  arguments  to  the  preceding  operation  and  may  be  any  of 


the  following: 

s litoral.  Literals  are  enclosed  In  quotes  when  they  appear  In  the 
operand  field  so  that  they  may  be  distinguished  from  lvalues. 

an  attribute  reference.  Note  that  It  is  possible  to  references 
attributes  of  attributes,  etc.  All  attribute  references  should  be  able 
to  be  resolved  at  compile  time  (l.e.,  there  should  be  an  appropriate 
definition  generated  at  some  point  In  the  expansion  of  the  IL 
program).  If  no  such  definition  exists  then  the  attribute  reference  Is 
Illegal. 

a reference  expression:  a simple  lvalue  If  the  "address"  of  the  cell 
is  needed;  otherwise,  an  rvalue  expression  (which  may  be  nested)  Is 
used. 

There  Is  no  a priori  restriction  on  the  complexity  of  a reference  expression,  but 
more  than  one  level  of  Indirection  (contents  operator)  will  likely  have  to  be 
calculated  In  a separate  statement.  By  convention,  at  most  a single  level  of 
Indirection  Is  used  In  an  operand. 


$2.3.3  The  END  and  ALIAS  pseudo-operations 

Pseudo-operations  provide  a mechanism  for  Informing  the  metainterpreter 
about  Information  difficult  (or  impossible)  to  derive  from  the  IL  program.  IL 
statements  with  pseudo-operators  are  "visible"  to  the  transformations  which  may 
transform  them  Into  ordinary  IL  statements,  etc.  but  they  become  "Invisible"  in  the 
final  translation  (l.e.,  they  are  not  output  In  the  resulting  target  machine  program). 
The  names  chosen  for  pseudo-operations  are  reserved  and  should  not  be  used  for 
other  purposes  by  the  designer;  In  this  thesis,  pseudo-operators  will  be  displayed  In 
upper  case  and  all  other  operators  displayed  In  lower  case. 

The  statement  In  which  the  END  pseudo-operation  appears  marks  the  logical 
end  of  an  IL  statement  sequence  - flow  analysis  for  that  sequence  will  not 
proceed  past  this  statement.  Statements  following  this  statement  up  to  the  next 
target  statement  (see  $2.4)  are  considered  Inaccessible  and  will  be  removed  by 
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the  metalnterpreter.  The  END  pseudo-operation  is  intended  for  use  at  the  end  of 
the  IL  program  and  for  marking  the  end  of  procedure  bodies  within  the  IL  program; 
presumably  some  transformation  will  translate  it  Into  a exit  or  return  as  appropriate. 
This  operation  makes  no  use  of  the  label,  operand,  or  attribute  Helds  and  so  may  be 
used  as  the  operator  of  a target  statement. 

The  ALIAS  pseudo-operation  provides  the  capability  of  defining  equivalence 
classes  of  lvalues  - any  member  of  an  equivalence  class  refers  to  the  same  rvalue 
(although  each  member  may  have  different  attributes  associated  with  it).  This 
operation  is  used  to  indicate  sharing  of  rvalues  (overlaying  of  storage)  as  declared 
by  the  source  language  program  (e.g.,  with  the  FORTRAN  EQUIVALENCE  statement) 
or  as  determined  in  some  transformation  (e.g.,  when  used  to  indicate  that  two  cells 
hold  the  same  value;  this  typically  occurs  during  optlmizat'on  when  a sequence  of 
statements  bolls  down  to  a move  from  one  cell  to  a temporary  - the  ALIAS 
operation  would  Indicate  that  the  temporary  is  aliased  with  the  original  cell).  In  the 
latter  case,  the  ALIAS  operation  provides  a renaming  capability  to  the 
transformation  designer.  The  form  of  the  ALIAS  statement  is 


Label 

Operator  Operands 

Attributes 

lvalue i 

ALIAS  lvalue2 

attributes... 

which  causes  the  metalnterpreter  to  place  lvalue 1 In  the  same  name  equivalence 
class  as  lvalue 2-  Note  that,  by  definition,  ALIAS  is  a transitive  operation.  Typically 
lvalue i Is  the  new  lvalue  to  be  defined  and  attributes...  are  Its  initial  attributes. 

$2.4  Flow  of  control  In  an  IL  program 

In  the  previous  sections,  the  syntax  and  semantics  of  a single  IL  statement 
were  described;  this  section  describes  the  semantics  of  a sequence  of  IL 
statements.  IL  statements  are  executed  sequentially,  modulo  explicit  transfers  of 
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control.  This  classic  control  structure  was  chosen  because  of  Its  compatibility  with 
the  control  structure  provided  by  most  target  machines  - the  operations  primitive 
to  IL  are  similar  to  those  provided  at  the  machine  level.  Sequential  execution  Is 
also  compatible  with  a wide  variety  of  languages,  especially  those  that  have 
relatively  severe  ordering  constraints  (e.g.,  ALGOL,  which  specifies  strict  left-to- 
rlght  evaluation  of  expressions).  This  control  structure  is  more  constraining  than 
the  one  provided  by  the  dags  on  which  IL  was  modeled:  the  only  constraint  Imposed 
by  dags  Is  that  the  sons  (operands)  of  an  Interior  node  (operation)  must  be 
evaluated  before  the  node  can  be  evaluated.  Some  languages  (e.g.,  BLISS)  take 
advantage  of  this  flexibility  In  expression  evaluation  by  only  Imposing  evaluation 
order  constraints  on  certain  operators  (such  as  BEGIN...END).  Such  flexibility  is  not 
Inherent  In  an  IL  program  and  must  be  provided  by  the  transformation  catalogue  and 
the  metainterpreter:  transformations  can  change  the  order  of  statements  In  an  IL 
program^. 

As  was  mentioned  at  the  beginning  of  this  chapter,  the  syntactic 
conventions  discussed  below  are  not  particularly  appropriate  for  languages  whose 
control  structure  differs  substantially  from  that  above.  SNOBOL,  for  example, 
requires  a "transfer  of  control"  with  every  statement  - the  difficulty  in 
accommodating  this  construct  In  IL  reflects  the  difficulties  In  producing  a SNOBOL 
compiler  for  conventional  machines;  perhaps  when  the  latter  problem  has  been 
solved,  the  solution  can  bs  Incorporated  In  IL. 

t In  general  these  transformations  only  change  the  evaluation  order  to  achieve 
some  goal,  for  example,  a reduction  In  the  number  of  registers  required  to  evaluate 
the  operator.  In  this  way  tha  conditions  under  which  evaluation  order  can  be 
modified  and  what  metrics  are  used  to  judge  the  result  are  made  explicit  in  the 
transformation  catalogue.  This  information  would  be  useful  during  the  analysis 
phase  of  a metacompiler  attempting  to  construct  a code  generator  from  the 
specification. 
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IL  statements  which  cause  a transfer  of  control  (transfer  statements)  are 
readily  Identified:  they  have  a "■*"  In  their  label  field.  Note  that  this  use  of  the 
label  field  prevents  the  statement  from  also  computing  (and  saving)  a value,  it  can 
only  effect  a transfer  of  control.  Procedure  calls  are  handled  differently:  since 
control  returns  to  the  statement  following  the  procedure  call,  they  are  similar  to 
ordinary  statements  except  for  the  possible  side  effects  of  the  procedure  body.  In 
$2.3.1,  a convention  for  the  label  field  for  procedure  calls  was  established  (listing 
the  side  effects  of  the  procedure);  thus,  no  transfer  Is  explicitly  indicated. 
Procedures  are  treated  as  "complex"  operations  In  so  far  as  this  section  Is 
concerned.  Note  that  a transfer  statement  always  transfers  control;  If  execution 
can  conditionally  continue  with  the  next  statement,  It  must  be  provided  for 
explicitly  by  adding  an  additional  label  statement. 

IL  statements  which  are  targets  for  a transfer  of  control  (target 
statements)  are  Identified  by  placing  a *•"  In  their  label  field.  As  for  transfer 
statements,  target  statements  cannot  compute  (and  save)  a value  since  their  label 
field  has  been  preempted.  The  following  convention  Is  used  by  the  metainterpreter 
for  determining  which  target  statements  are  possible  targets  for  a given  transfer 
statement: 

a target  statement  Is  a target  for  a given  transfer  statement  Iff  the 
same  lvalue  appears  as  some  operand  of  both  the  target  statement 
and  the  transfer  statement. 

This  convention  allows  additional  arguments  to  transfer  snd  target  statements 
which  can  be  used  by  the  operator  of  these  statements.  The  following  example 
(extracted  from  Figure  2.2b)  illustrates  the  convention  more  clearly: 
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Label 

-♦ 

e 

••• 

e 


Operator 
If  .goto 
label 

label 


Operands 
<T100>  LI  L4 
LI 

L4 


Attributes 


The  first  line  Is  a transfer  statement  (has  -»  In  Its  label  field)  which  can  transfer 
control  to  either  of  the  target  statements.  The  second  statement  is  recognized  as 
a possible  target  since  the  lvalue  LI  Is  an  operand  of  both  the  first  and  second 
statement;  similar  reasoning  holds  for  the  last  target  statement.  It  is  not  possible 
to  tell  from  the  above  program  the  circumstances  under  which  either  label  is 
chosen  as  that  depends  on  the  semantics  of  the  lf_goto  operation  (and  presumably 
the  value  of  T1 00),  information  that  only  exists  In  the  transformation  catalogue. 

This  Information  Is  used  by  the  metainterpreter  to  construct  a "maximal"  flow 
graph  for  the  IL  program.  The  flow  graph  Is  maximal  In  the  sense  that  all  possible 
targets  are  considered  for  each  transfer  statement,  even  those  which  may  be 
ruled  out  by  the  semantics  of  the  operator  of  the  transfer  statement.  This  graph 
serves  as  the  basis  for  the  flow  analysis  performed  by  the  metainterpreter  and  is 
updated  whenever  a transformation  changes  or  eliminates  a transfer  statement. 


$2.6  Compile- time  calculation  of  rvalues 

One  of  the  goals  for  the  syntax  of  IL  Is  to  allow  the  complle-time  calculation 
of  rvalues.  This  section  briefly  touches  on  the  resolution  of  rvalues  (and  lvalues) 
using  the  notation  developed  In  earlier  sections.  In  this  section,  set  notation  Is 
used  to  Indicate  possible  values  for  a reference  expression,  e.g.,  if  the  rvalue  of  I 
Is  known  to  be  either  3 or  4 then  we  write  <l>  ■ {3  4).  If  the  value  of  a 
reference  expression  is  unknown  (l.e.,  It  could  be  any  possible  value)  then  we 
write  <"}. 
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Occasionally,  It  is  possible  to  further  resolve  a particular  reference 
expression.  If  <l>  = {3  4}  then 

<A>.<I>  = <A>.{3  4}  = {<A>.3  <A>.4). 

If,  on  the  other  hand,  the  value  of  I is  unknown  «l>  * {*})  then 

<A>.<I>  = <A>.{*>  = <A> 

IL  recognizes  the  alternative  forms  In  each  example  as  equivalent:  In  effect,  such 
resolution  Is  performed  automatically.  Even  In  the  absence  of  knowledge  about  the 
rvalue  of  I,  a reasonable  interpretation  of  lvalues  incorporating  <l>  Is  possible, 
erring  only  in  that  it  Is  likely  to  be  an  overly  conservative  interpretation.  In  the 
second  example  above,  the  distinction  between  as  an  abbreviation  for  all 
possible  component  names  and  {*}  as  the  representation  for  all  possible  values  has 
been  deliberately  blurred.  The  Intent  behind  assigning  numeric  selectors  for  the 
components  of  the  array  A Is  to  allow  this  sort  of  felicitous  confusion. 

As  a rule  of  thumb,  the  utility  of  the  complle-tlme  computation  of  a cell's 
rvalue  Is  inversely  proportional  to  the  size  of  the  value  set.  There  are  several 
contributing  factors:  as  the  size  of  the  value  set  Increases,  it  becomes 
Increasingly  unlikely  that  any  significant  optimizations  will  be  possible  for  rvalue 
operations  on  that  cell.  In  addition,  uncertainty  In  one  celTs  rvalue  tends  to 
propagate  to  other  cells  whenever  the  first  cell  is  used  as  an  operand  (the  value 
set  of  an  operation  Is  proportional  to  the  product  of  the  value  sets  of  the 
operands).  Such  "dilution"  of  complle-tlme  Information  is  not  unexpected  - It  would 
be  unreasonable  to  expect  to  perform  all  computations  at  compile  time!  However, 
the  prognosis  at  this  point  Is  not  encouraging:  It  would  appear  that  large  amounts 
of  compile-time  information  could  be  collected  with  little  prospect  of  a 
corresponding  gain  In  the  optimality  of  the  resulting  translation. 
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The  preceding  peragraph  prompts  two  observations:  compile- time  calculation 
of  rvalues  Is  subject  to  the  law  of  diminishing  returns,  and  therefore  rvalues  are 
not  suitable  for  cell  attributes  thet  do  not  change  with  each  operation  on  the  cell. 
The  first  observation  serves  as  further  motivation  for  the  introduction  of  {”}  for 
rvalue  sets  which  have  grown  too  cumbersome.  The  second  suggests  that 
attributes  are  a useful  addition  to  the  semantics  of  a cell  because  they  provide  a 
mechanism  for  circumventing  the  vagaries  of  rvalue  computations. 
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$3.1  The  transformation  catalogue 

A major  design  goal  for  the  IL/ML  system  was  to  keep  knowledge  about  the 
source  language  and  target  machine  separate  from  general  knowledge  about  code 
generation.  This  was  accomplished  by  providing  for  a separate  description  of 
machine-  and  language-dependent  semantics  — the  embodiment  of  this  description  is 
the  transformation  catalogue.  Each  piece  of  language-  or  machine-specific 
information  is  expressed  as  a syntactic  transformation  of  an  IL  program  fragment; 
after  the  transformation  has  been  applied,  the  updated  program  will  have  been 
modified  to  incorporate  this  new  information  In  terms  the  metainterpreter 
understands:  as  attributes  or  a new  sequence  of  IL  statements.  The 
metainterpreter  provides  the  remainder  of  the  framework  needed  to  finish  the  task 
of  code  generation:  whenever  It  exhausts  Its  analysis  of  the  current  program  it 
returns  to  the  transformation  catalogue  to  gather  additional  Information  (in  the  form 
of  a "new"  IL  program  to  analyze).  This  cycle  of  analysis  and  transformation 
repeats  until  the  translation  Is  complete. 

This  chapter  discusses  the  transformation  catalogue  and  the  language  which 
serves  as  its  basis:  a metalanguage  (ML)  for  describing  IL  program  fragments. 
Using  ML,  the  designer  can  write  templates  which  describe  the  class  of  IL 
statements  in  which  he  Is  interested.  This  class  can  be  quite  large  (e.g.,  "all  IL 
statements  which  have  commutative  operators")  or  quite  small  (e.g.,  "only 
statements  which  apply  the  sine  operator  to  the  argument  3.14160")  depending  on 
the  application  the  designer  has  in  mind.  Members  of  the  class  of  IL  fragments 
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described  by  a template  are  said  to  match  the  template.  $3.2  presents  a detailed 
description  of  the  syntax  of  ML. 

Two  templates  are  Incorporated  In  each  transformation:  one  as  a pattern,  the 
other  as  a replacement.  The  pattern  specifies  the  context  of  the  transformation  as 
a set  of  program  fragments  on  which  the  transformation  can  operate^.  IL 
statement(s)  which  match  the  pattern  become  candidates  for  the  modifications 
specified  by  the  replacement.  The  replacement,  perhaps  using  statements  or 
components  matched  by  the  pattern,  tells  how  to  construct  a new  IL  program 
fragment  to  be  aubst'tuted  for  the  matched  fragment. 

The  use  of  transformations  Is  a well-established  technique  for  embodying 
knowledge  for  later  use  In  a mechanized  fashion  (see  $1.3.1).  If  all  the  contextual 
Information  in  the  data  base  (in  this  case,  the  IL  program)  is  available  in  syntactic 
form,  patterns  provide  a concise  description  of  where  the  piece  nf  Information 
captured  by  the  transformation  Is  applicable.  Using  the  transformation  catalogue  Is 
reduced  to  finding  a transformation  which  matches  the  given  IL  statement  (or  any  IL 
statement,  If  the  metainterpreter  has  no  specific  goal  in  mind);  alternatively,  the 
replacement  (which  ia  also  a pattern)  can  be  examined  to  determine  If  it 
accomplishes  the  desired  effect.  The  ability  to  use  transformations  from  either  end 
enhances  their  utility  as  the  basis  for  knowledge  representation. 

$3.3  describes  how  transformations  are  constructed  and  how  they  are  used 
by  the  metainterpreter.  The  final  section  of  this  chapter  presents  a series  of 
annotated  example  transformations. 


t This  context  can  be  further  modified  by  a set  of  conditions  specifying 
constraints  which  are  not  expressible  in  terms  of  the  syntax  of  the  IL  program 
(see  $3.3.1). 
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$3.2  ML:  a language  for  describing  IL  program  fragments 

ML  Is  similar  to  other  metalanguages  - its  syntax  subsumes  that  of  IL  (l.e., 
an  IL  statement  Is  a legal  ML  statement)  and,  In  addition,  It  allows  certain 
metasymbols  to  replace  IL  components  or  statements.  The  metasymbols  come  in 
two  flavors:  wild  cards  that  act  as  "don’t  cares"  In  the  matching  process,  and  calls 
to  built-in  functions  that  allow  access  to  some  of  the  metainterpreter's  knowledge 
of  IL  program  semantics.  Use  of  these  metasymbols  permits  the  designer  to  write 
generalized  IL  program  fragments;  these  fragments  are  more  general  than  an  IL 
program  fragment  because  the  designer  has  constrained  only  those  statement 
components  in  which  he  is  interested  (using  wild  cards  to  specify  the  remaining 
components). 

However,  the  designer  can  only  generalize  along  certain  dimensions  as  his 
only  access  to  the  meaning  of  an  IL  statement  is  its  syntactic  form  and  whatever 
built-in  functions  are  available  (see  $3.2.2).  Since  the  separate  fields  for  kilt  sets 
and  attributes  In  an  IL  statement  seem  to  be  as  far  as  one  can  go  towards  making 
the  syntactic  form  of  an  IL  statement  reflect  the  statement’s  semantics  without 
limiting  the  generality  of  IL,  the  limiting  factors  are  the  capabilities  of  the  built-in 
functions.  The  designer  can  determine  whether  two  literals  are  the  same  but  may 

not  be  able  to  find  out,  for  example,  whether  the  square  root  of  a literal  Is  an 

Integer.  These  restrictions  on  the  abilities  of  built-in  functions  are  the  most  severe 
limitation  of  ML:  building  in  language-  and  machine-specific  predicates  into  ML  is 

ruled  out  as  this  effects  the  generality  of  the  system  and,  unfortunately,  it  would 

be  impossible  to  include  all  the  generally  useful  functions.  Lest  we  be  accused  of 
making  a mountain  out  of  a molehill,  it  should  be  pointed  out  that  the  result  of  these 
limitations  Is  missed  optimization  opportunities.  Presumably  all  the  computations 
specified  in  the  IL  program  could  be  done  at  execution  time;  the  computational 
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facilities  provided  by  ML  are  intended  to  allow  special  tailoring  of  the 
transformations  and  not  to  be  an  essential  component  of  the  transformations.  ML 
takes  the  middle  road  by  providing  built-in  functions  for  manipulation  of  literals  and 
for  Interpreting  literals  as  numeric  quantities  - other  functions  must  be  constructed 
from  these  by  Including  the  appropriate  transformations  in  the  catalogue.  These 
additions  to  the  catalogue  are  sufficient  for  most  purposes  - for  example,  the 
catalogue  may  contain  transformations  for  simplifying  the  application  of  the 
transcendental  functiona  to  certain  arguments  (»,  */2,  etc.)  but  would  translate  all 
other  applications  to  a run-time  call  of  the  appropriate  function. 

§3.2.1  describes  wild  cards;  §3.2.2  enumerates  some  example  built-in 
functions.  Example  ML  statements  can  be  found  In  the  last  section  of  the  chapter 
as  patterns  and  replacements  in  transformations. 

§3.2.1  Wild  cards 

Wild  card  metasymbols  are  used  as  components  of  an  ML  atatement 
wherever  a specific  IL  component  would  be  too  restrictive  - the  wild  card  will 
match  any  IL  component(s).  The  discussion  below  describes  the  meaning  of  ML 
statements  when  used  in  a pattern;  to  a large  degree  the  semantics  of  a 
replacement  are  similar  (dlfferances  are  described  In  §3.3.2).  There  are  four  forms 
of  wild  card: 

wild  card  will  match 

7 name  a single  IL  component 

$name  a single  IL  statement 

?"name  a sequence  of  IL  components 

9"name  a sequence  of  IL  statements 

name  Is  an  optional  Identifier  which  is  used  to  distinguish  between  multiple  wild 
cards  used  in  a single  pattern  or  replacement.  These  names  are  also  used  in  the 
replacement  to  refer  to  components  or  statements  matched  in  the  pattern.  If  a 
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given  wild  card  appears  more  than  once  In  a pattern  or  replacement  (l.e.,  two  or 
more  wild  cards  with  the  same  form  and  name)  they  are  understood  to  represent 
the  same  IL  component;  If  this  duplication  occurs  within  a pattern  then  all  the 
copies  must  match  IL  components  with  the  same  representation. 

The  ? and  $ wild  cards  match  a single,  non-null  component  or  statement 
respectively,  l.e.,  for  each  ? ($)  there  must  be  a corresponding  IL  component 
(statement)  in  the  IL  program  fragment  which  la  being  matched.  Note  that  when 
describing  an  IL  statement,  all  of  Its  components  (with  the  exception  of  attributes, 
see  $3.3.2)  must  be  accounted  for  In  the  ML  statement  - either  explicitly  or  as 
wild  cards  - or  the  match  will  fall.  Thus,  If  only  the  label  field  Is  to  be  constrained 
in  the  pattern,  wild  card  components  must  be  used  for  the  contents  of  the  operator 
(use  ? wild  card)  and  operand  (use  ?"  wild  card)  fields. 

The  ?*  wild  card  matches  any  sequence  of  zero  or  more  IL  components 
within  a single  held  - what  components  are  matched  usually  depends  on  the 
components  on  either  side  of  the  ?"  wild  card  In  the  ML  statement.  If  these 
adjacent  components  constrain  the  match  for  the  ?"  wild  card  to  a single 
sequence,  the  7"  wild  card  Is  said  to  be  unambiguous.  In  general,  if  more  than  one 
?*  wild  card  Is  used  In  a single  field,  they  may  be  ambiguous;  this  is  always  the 
case  if  two  ?*  wild  cards  are  adjacent  or  separated  by  any  number  of  ? wild 
sards.  Even  If  specific  IL  components  are  Interposed,  duplication  of  this  component 
in  the  IL  field  can  cause  the  ?*  wild  cards  to  be  ambiguous.  For  example,  consider 
the  sequence  of  components  "A  B C C D".  There  are  two  ways  In  which 
components  can  be  assigned  to  the  ML  expression  "?x  ?*y  C ?*z": 

?X="A"  ?*yB"B"  ?*z*"C  D"  or  ?x«"A"  ?»y“"B  C"  ?«z«"D". 

Ambiguous  wild  cards  are  useful  for  matching  a specific  IL  component  anywhere  In  a 
field;  e.g.,  the  following  ML  statement  matches  any  add  statement  which  has  at 
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least  one  "0"  operand: 


Label 

Operator  Operands 

Attributes 

Tlabel 

add  ?*opa1  "0"  ?*ops2 

?*attributes 

If  "add"  is  a binary  operator,  one  of  ?"ops1  and  ?*ops2  will  be  assigned  no 
components  during  the  match.  The  ?*attrlbutes  wild  card  shows  the  more 
traditional  use  of  unambiguous  wild  cards  to  match  a whole  field  for  later  replication 
In  the  replacement. 

The  $*  wild  card  matches  a sequence  of  zero  or  more  IL  statements.  Unlike 
?*  however,  the  sequence  is  not  determined  by  lexical  juxtaposition  in  the  IL 
program  but  by  flow  of  control:  statements  are  considered  adjacent  in  the  process 
of  matching  if  one  might  follow  the  other  in  execution.  Branches  and  joins  in  the 
flow  of  control  often  result  In  more  than  one  possible  sequence  of  statements  that 
could  match  a $*  wild  card.  For  example,  consider  the  IL  program  given  In  Figure 
2.1  and  the  following  sequence  of  ML  statements: 


Label 

Operator 

Operands 

Attributes 

Z 

declaration 

$»A 

z 

Top 

Figure  3.1  shows  the  two  possible  sequences  of  IL  statements  that  could  be 
matched  by  $*A.  In  such  cases,  both  sequences  are  saved  as  possible  values  for 
$*A.  The  most  common  use  of  $*  wild  cards  (and  the  sets  of  statement  sequences 
that  they  match)  Is  to  establish  the  context  of  a transformation  - there  exist 
built-in  functions  that  test  these  sequences  for  simple  properties  (e.g.,  presence  of 
a given  lvalue  In  the  label  field  of  at  least  one  statement  In  one  of  the  sequences). 
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Label 

Operator 

Operands 

Attributes 

Cl 

constant 

<C1  >:type=lnteger 

C2 

constant 

"3" 

<C2>:type*lnteger 

T1 

greater.than 

<X>  <Y> 

If.goto 

<T1  > L2  LI 

e 

label 

LI 

X 

store 

<C2> 

Y 

store 

<C1> 

-♦ 

goto 

L3 

* 

label 

L3 

T2 

add 

<X>  <Y> 

Label 


Cl 

C2 


Operator  Operands 

Attributes 

constant  "2" 

constant  "3" 

greater.than  <X>  <Y> 
if.goto  <T1  > L2  LI 

label  L2 

store  <C1> 

store  <C2> 

label  L3 

add  <X>  <Y> 

<C1>:typesinteger 

<C2>:type=integer 

Figure  3.1:  Matches  for  $*A  from  Figure  2.1 


$3.2.2  Built-in  function* 

Built-In  functions  are  used  In  ML  statements  to  perform  operations  that 
require  more  power  than  simply  rearranging  an  IL  statement.  A call  on  a built-in 
function  has  the  following  form: 

functlon[argument 1 ,...  .argument^ 

The  use  of  square  brackets  distinguishes  built-in  function  calls  from  ordinary  IL 
components  (which  are  restricted  to  the  use  of  parentheses).  All  functions  return 
a result  (no  side  effects  are  possible);  this  result  can  be  used  as  the  argument  to 
another  built-in  function  or,  If  the  call  was  part  of  a replacement,  become  part  of  an 
IL  program.  The  arguments  to  a function  may  be  written  as  either  IL  or  ML 
components  but  they  must  be  able  to  be  resolved  by  the  metainterpreter  to  a 
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particular  IL  component  (or  IL  statement  sequence  for  certain  functions).  In  the 
process  of  applying  the  function  to  its  arguments,  the  function  may  abort  causing 
the  application  of  the  transformation  to  fall  regardless  of  the  location  of  the 
function  call  (pattern,  replacement,  or  conditions).  The  main  reason  for  aborting  a 
function  is  an  inappropriate  argument,  e.g.,  the  argument  has  the  wrong  type, 
cannot  be  resolved  to  a literal,  etc.  For  Instance,  the  add  function  aborts  If  both 
operands  are  not  literals  that  can  be  Interpreted  as  numeric  quantities. 

By  way  of  example,  several  functions  are  described  below;  this  list  is  not 
meant  to  be  complete  - only  a sampling  of  each  category  of  function  have  been 


described.  It  is  expected  that  an  implementation  would  expand  the  list;  the  only 


criterion  for  Including  a function  Is  that  It  not  cater  to  a specific  language  or 


machine.  The  following  argument  types  are  used  In  describing  functions: 

component  Any  IL  component  Is  an  acceptable  argument. 

literal  The  argument  must  be  an  IL  literal  (l.e.,  an 

operator,  attribute  reference,  or  operand 
enclosed  In  quotes). 


number  The  argument  must  be  an  IL  literal  which  can  be 

Interpreted  as  a number  (l.e.,  It  contains  only 
digits,  a decimal  point,  and  a sign). 

boolean  The  argument  must  be  one  of  the  IL  literals 

"true"  or  "false". 

sequence  The  argument  must  be  the  result  of  a $*  wild 

card  match  (l.e.,  a set  of  IL  statement 
sequences). 

If  the  supplied  argument  does  not  have  the  correct  type,  the  metainterpreter  will 


abort  the  application  of  the  function  and  hence  the  application  of  the 

transformation  in  which  it  appears. 

and[6oo/ea/i,boo/ean] 
or[boolean, boolean] 


64. 


Chapter  Three  - ML:  a language  for  describing  IL  program  fragments 


not[  boo/ean] 

the  standard  boolean  functions  evaluating  to  the  literals  "true"  or 
"false"  as  appropriate.  These  are  used  most  often  In  conjunction 
with  other  functions  to  form  more  complicated  expressions. 

equal  [llteraljlteral] 

compares  two  literals  to  see  If  th9y  have  the  same  representation; 
evaluates  to  "true"  if  they  do,  "false"  otherwise.  Note  that  equal 
cannot  be  used  to  compare  two  arbitrary  IL  components  - this  can 
usually  be  accomplished  directly  In  the  pattern  by  using  the  same 
wild  card  name  In  both  component  locations. 

constant[component] 

evaluates  to  "true"  if  the  argument  is  a literal,  "false"  otherwise. 
lvalue[compone/jf] 

evaluates  to  true  if  the  argument  represent  a valid  lvalue. 

Iabel[/abe/, sequence] 

evaluates  to  "true"  If  any  member  of  the  augmented  kill  set 
represented  by  label  appears  In  the  label  field  of  a statement 
contained  in  the  set  of  IL  statement  sequences  sequence.  This 
function  determines  whether  a cell(s)  has  been  modified  In  an  IL 
statement  sequence.  The  label  function  is  representative  of 
functions  that  search  IL  statement  sequences  for  simple  properties; 
other  functions  that  test  for  properties  in  every  sequence  and  search 
other  statement  fields  should  be  included. 

add  [number, number] 
subtract  [number, number] 
multiply  [number  .number J 
dlvid  e[number, number"] 

the  standard  arithmetic  functions  returning  the  appropriate  numeric 
literal.  In  order  to  avoid  representation  problems,  a precision  limit 
may  be  set  by  the  Implementation. 

power_of_two[number] 

evaluates  to  "true"  If  the  argument  Is  a numeric  literal  which  is  a 
power  of  two,  "false"  otherwise.  This  function  Is  useful  for 
determining  when  to  change  multiplications  and  divisions  Into  shifts. 

This  example  represents  the  tip  of  the  Iceberg  when  It  comes  to 
useful  arithmetic  functions  - a reasonable  subset  might  be  to  Include 
only  operations  on  binary  representations  (binary  log,  logical  and 
arithmetic  shifts,  etc.). 

Choices  of  the  domain  (arguments  for  which  the  function  will  not  abort)  for  the 
predicates  described  above  have  been  made  arbitrarily.  All  that  really  matters  Is 
that  the  choices  are  consistent  with  the  use  of  the  functions  In  the  transformation 
catalogue. 
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$3.3  Transformations  and  pattern  matching 


A transformation  Is  made  up  of  three  components:  a pattern,  a replacement, 
and  a set  of  conditions.  The  pattern  (an  ML  program  fragment)  and  the  conditions 
(a  set  of  predicates)  establish  the  context  of  the  transformation  by  identifying 
those  IL  program  fragments  on  which  the  transformation  can  operate.  A contiguous 
group  of  statements  within  the  pattern  Is  designated  as  the  target  - these 
statements  must  be  contiguous  as  they  will  be  replaced  in  their  entirety  by  the 
new  IL  program  fragment  constructed  from  the  replacement  once  the  context  has 
been  verified^. 

The  following  criteria  must  be  met  before  a transformation  can  be  applied: 

(1)  all  components  of  the  pattern  must  match  some  component  In  the  IL 
program  fragment  (and  vice  versa).  Duplicated  wild  cards  must  have 
matched  IL  components  with  the  same  representation. 

(2)  each  of  the  conditions  must  evaluate  to  true.  If  any  condition  aborts 
(see  $3.2.2),  the  application  of  the  transformation  fails.  Note  that 
conditions  may  use  named  wild  cards  from  the  pattern  as  part  of  an 
argument;  these  wild  cards  will  be  replaced  by  the  IL  component(s) 
they  matched  during  (1)  before  evaluation  of  the  function. 

(3)  the  target  must  be  a contiguous  group  of  statements  from  the 
matched  IL  program  fragment. 

(4)  the  replacement  must  be  successfully  constructed  - each  in-line 
built-in  function  call  must  be  evaluated  without  aborting. 

If  all  these  criteria  are  met,  the  newly  constructed  replacement  Is  substituted  for 

the  target,  completing  the  application  of  the  transformation. 

The  following  section  describes  the  syntax  of  a transformation  in  more 

detail;  $3.3.2  outlines  how  the  replacement  is  constructed. 


t Statement  sequences  matched  by  $*  wild  cards  cannot,  in  general,  be  used  In  a 
target  since  they  do  not  necessarily  contain  lexically  adjacent  statements.  For 
similar  reasons,  $*  wild  cards  are  seldom  used  In  the  specification  of  a 
replacement. 
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§3.3.1  The  syntax  of  a transformation 

A transformation  has  the  following  form: 


Label  | Operator  Operands  | Attributes 
...  pattern  goes  here  ... 


replacement  goes  here  ... 


...  conditions  go  here  ... 


The  first  section  contains  the  ML  program  fragment  which  serves  as  the  pattern, 
the  second  section  contains  the  replacement  (also  an  ML  program  fragment),  and 
the  final  section  contains  a set  of  conditions  (If  no  conditions  are  needed,  the  final 
section  may  be  omitted).  Target  statements  within  the  pattern  are  indicated  by  a 
double  vertical  bar  to  their  left.  For  example: 


Label 

Operator 

Operands 

Attributes 

beq 

Tdestl  ?next 

locatlon=?branch_pc 

e 

label 

?next 

Jmp 

?dest2 

e 

label 

Tdestl 

$* 

e 

label 

Tdest2 

location=Tdest_pc 

bne 

Tdest2  Tdestl 

location*?branch_pc 

| conditions:  less_than[subtract[?de8t_pc1?branch_pc],M266M] 

In  this  transformation  the  first  three  statements  of  the  pattern  are  the  target  and 
will  be  replaced  by  the  single  statement  replacement  when  the  transformation  Is 
applied.  The  remaining  statements  matched  by  the  pattern  (two  labels  and  the 
Intervening  statements)  will  be  unchanged.  The  intent  of  the  transformation  is  to 
use  the  short  address  form  for  the  Jump-if-not-equal  construct  formed  by  the  first 
three  statements  If  the  ultimate  destination  (?der.t2)  Is  not  too  far  away  (less  than 
266  bytes).  This  transformation  only  handles  forward  Jumps  - another 
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transformation  would  be  needed  to  accommodate  jumps  In  the  other  direction. 
Other  points  to  note:  the  use  of  duplicate  wild  cards  to  specify  that  the  same  IL 
component  must  appear  In  more  than  one  place;  the  first  snd  last  statement  of  the 
matched  fragment  must  have  location  attributes. 

With  one  exception,  each  component  of  the  matched  IL  program  fragment 
must  be  subsumed  by  some  component  of  the  pattern.  The  contents  of  the 
attribute  field  are  exempt  from  this  condition  - attributes  in  the  IL  fragment  that 
are  not  named  in  the  pattern  do  not  enter  Into  the  matching  process.  The  use  of  a 
?*  wild  card  to  capture  the  unspecified  attributes  for  later  replication  in  the 
replacement  is  not  necessary  as  there  are  special  rules  concerning  them  in 
construction  of  the  replacement  (see  $3.3.2).  Thus,  attributes  are  largely 
transparent  to  a transformation;  the  information  they  contain  is  automatically  copied 
to  the  updated  program  wherever  necessary.  New  attributes  may  be  added  to  any 
statement  or  cell  by  simply  including  the  appropriate  assignment  in  the  replacement. 
In  the  example  above,  a location  attribute  is  defined  for  the  new  "bne"  statement 
with  the  same  value  as  the  location  attribute  for  the  original  "beq"  statement. 

A new  rvalue  for  a cell  may  be  Indicated  to  the  metainterpreter  by  Including 
an  assignment  to  the  rvalue  (similar  to  the  definition  of  an  attribute)  in  the  attribute 
field  of  the  appropriate  statement  in  the  replacement.  For  example,  the  following 
transformation  replaces  the  addition  of  two  constants  with  a store  operation, 
Indicating  that  the  destination  of  the  store  has  acquired  a new  value  which  is  the 
sum  of  the  constants. 


| Label 

Operator  Operands 

Attributes 

|?dest 

plus  ?op1  ?op2 

f ?deat 

store  addr?oo1.?op2l 

<?dest>aaddr?op1  ,?op2l 

| conditions:  and[number[?op1],number[?op2]] 

The  result  from  the  call  to  add  in  the  operand  field  of  the  replacement  will  be 
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automatically  surrounded  by  quotes  (to  Indicate  that  the  new  operand  is  a literal). 

The  number  built-in  function  returns  "true"  if  its  argument  is  a numeric  literal;  the 
condition  could  be  omitted  entirely  as  add  aborts  If  Its  arguments  are  not  numeric 
literals,  causing  the  transformation  to  fail.  Note  that  the  rules  mentioned  in  the 
previous  paragraph  will  ensure  that  any  attributes  defined  for  ?dest  In  the  o-lginal 
statement  will  be  added  to  the  attribute  field  for  the  store  statement.  Finally,  it  is 

i 

worth  pointing  out  that  ?op1  and  ?op2  do  not  heed  to  be  literals  In  the  original 

program  - ?op1  and  ?op2  need  only  be  able  to  be  resolved  to  literals  when  the  1 

transformation  Is  applied.  For  example,  the  statement  "add  <X>  <Y>"  would  match 

the  pattern  if  <X>  and  <Y>  were  both  known  to  have  constant  values.  These 

values  would  have  been  established  In  previous  statements  by  Including 

assignments  to  <X>  and  <Y>  in  the  attribute  fields  of  those  stateness. 

$3.3.2  Constructing  the  replacement 

Two  capabilities  are  provided  by  the  replacement  that  have  not  been 
discussed  previously:  the  generation  of  new  symbols  unused  elsewhere  in  the 
program  and  the  automatic  handling  of  attributes.  The  ability  to  generate  an 
unused  symbol  is  necessary  when  the  transformation  expands  a single  statement 
Into  a series  of  new  statements  as  temporary  cells  used  by  the  new  statements 
need  to  be  supplied  names  that  are  not  used  elsewhere  In  the  program.  Automatic 
handling  of  attributes  enables  the  designer  to  Ignore  attributes  with  which  he  Is  not 
directly  concerned  and  guarantees  that  no  attribute  information  will  be  lost  through 
an  oversight  In  composing  the  transformation. 

When  expanding  the  specification  of  the  replacement  to  arrive  at  the  new 
program  fragment  all  wild  cards  must  be  eliminated.  If  the  wild  card  has  the  same 
form  and  name  as  one  which  appeared  In  the  pattern,  the  IL  component  matched  by 
that  wild  card  serves  as  Its  value  In  the  replacement.  For  Instance,  applying  the 
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last  transformation  in  the  previous  section  to 


Label 

Attributes 

A.1 

add  "64"  "40" 

would  result  In  the  replacement 


Label 

Operator  Operands 

Attributes 

A.1 

store  "04" 

<A.1  >=94 

If  a ? wild  card  In  the  replacement  does  not  correspond  to  some  wild  card  in  the 
pattern  (l.e.,  Its  name  Is  different  from  any  used  In  the  pattern),  a new  lvalue  Is 
created  to  be  used  as  Its  value.  The  new  lvalue  Is  guaranteed  to  be  different  from 
any  used  in  the  remainder  of  the  1L  program.  Note  that  the  designer  must  include 
any  attributes  to  be  associated  with  the  new  lvalue  as  part  of  the  transformation. 
If  there  are  no  wild  cards  in  the  pattern  that  correspond  to  $,  ?*,  and  $*  wild 
cards  in  the  replacement,  the  transformation  is  illegal  and  will  never  be  applied. 

As  an  example  of  generated  lvalues  consider  the  following  transformation 
concerned  with  the  expansion  of  the  subscript  operator: 


Label 

Operator  Operands 

Attributes 

iraai 

subscript  ?array  ?index 

?ptr:  c lass = temper  ary 

?ti 

7t2 

7t3 

?ptr 

convert  ?index 

subtract  <?t1>  ?array:lower_bound 

multiply  <7t2>  <7array>.*:alze 

add  <7t3>  ?array 

?t1  :class=temporary 
<?t1  >:type*integer 

7t2 : class=tempora  ry 

<7t2>  :type«lnteger 

7t3:class=temporary 

<7t3>  :type«lnteger 

«7ptr»:type»<?array>.*:type 

The  convert  operator  In  the  first  line  of  the  replacement  will  coerce  the  value  of 
the  Index  to  type  "Integer"  (see  $3.4  for  a sample  definition  of  convert).  ?t1,  ?t2, 
and  7t3  are  all  new  cells  which  will  be  named  when  this  transformation  is  applied; 
?ptr,  ?array,  and  ?lndex  will  be  taken  from  the  subscript  statement  matched  by  the 
pattern.  Note  that  pertinent  attributes  for  the  new  cells  have  been  defined  in  the 
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transformation.  The  attribute  defined  In  the  last  line  of  the  replacement  Indicates 
that  the  type  of  the  value  pointed  to  by  ?ptr  Is  the  same  as  the  type  of  an 
element  In  the  array  being  subscripted. 


The  following  rules  are  used  In  establishing  attributes  for  statements  In  the 
replacement: 

1.  Every  attribute  definition  In  the  target  statements  will  be  copied  to 
the  attribute  field  of  some  statement  In  the  replacement  by  the 
metainterpreter  when  it  applies  the  transformation.  Where  possible 
the  statement  chosen  In  the  replacement  field  will  have  the  same 
label  as  the  defining  statement  In  the  target  - this  does  not  make 
any  difference  as  far  as  defining  the  attribute  Is  concerned,  but  It 
Improves  the  documentation  value  of  the  definition.  If  they  are  no 
statements  in  the  replacement  (the  target  is  being  completely 
eliminated),  some  other  statement  in  the  updated  program  Is  chosen 
to  receive  the  definitions. 

2.  If  applying  a transformation  would  result  in  a conflicting  attribute 
definition  (l.e.,  two  or  more  definitions  of  the  same  attribute  with 
different  values),  the  transformation  fails. 

3.  Statement  attributes  are  never  copied  to  the  replacement;  only  cell 
attributes  are  updated. 

Rule  2 ensures  that  once  defined,  attributes  can  be  counted  on  to  maintain  their 
original  value  (l.e.,  attribute  definitions  are  conserved). 


$3.4  Example  transformations 

The  first  example  is  a transformation  which  expands  the  coercion  operator 
used  in  the  sample  expansion  of  subscript  in  the  previous  section.  The  convert 
operator  coerces  its  argument  to  have  the  type  of  destination  cell;  It  assumes  that 
types  are  constrained  to  be  one  of  "integer"  or  "real". 
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Label 

Operator 

Operands 

Attributes 

|?result 

convert 

Targ 

-> 

If.goto 

equal[Tresult:type,Targ:type]  TL1 

TL2 

e 

label 

TL1 

Tresult 

store 

Targ 

•+ 

goto 

TL5 

e 

label 

TL2 

if.goto 

equal[Tresult:type, "integer"]  TL3 

TL4 

e 

label 

TL3 

Tresult 

real.to.int 

Targ 

goto 

TL6 

e 

label 

TL4 

Tresult 

lnt_to_real 

Targ 

e 

label 

TL6 

It  Is  expected  that  all  the  testing  and  branches  can  be  done  at  compile  time.  For 
example,  If  Targ:type=lnteger  and  Tresult:type=real  then  the  replacement  can  be 
reduced  to  a single  statement  by  elimination  of  dead  code  and  complle-time 
evaluation  of  the  if.goto  operations.  Although  this  transformation  is  lengthy  due  to 
the  lack  of  any  sugaring  In  ML  for  dispatching  on  the  values  of  attributes,  It  was 
straightforward  to  construct.  Note  that  this  transformation  cannot  be  applied  If 
either  ?arg:type  or  ?result:type  Is  undefined  (equal  will  abort).  Through  the  use  of 
conditions,  It  would  be  possible  to  rewrite  the  single  transformation  above  as  three 
separate  transformations,  one  for  each  of  the  cases  treated;  the  amount  of 
optimization  required  to  achieve  the  same  result  as  above  would  be  considerably 
reduced. 

The  following  series  of  transformations  deal  with  the  expansion  of  the  store 

operator.  Unlike  the  transformation  above,  these  expansions  must  be  done  In 

separate  transformations  because  of  the  use  of  the  ALIAS  operator^.  The  first 

transformation  handles  the  case  where  the  store  operation  can  be  eliminated 

completely  because  the  destination  Is  a newly  defined  temporary  and  the  value 

t The  ALIAS  operator,  like  attributes,  provides  Information  which  Is  Independent  of 
the  flow  of  control;  branches  cannot  prevent  "execution"  of  the  alias  operation. 
Thus,  the  strategy  used  for  expanding  the  convert  operator  cannot  be  used. 
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being  stored  Is  already  contained  In  an  accessible  cell.  In  this  case,  all  that  needs 
to  be  done  Is  alias  the  temporary  to  the  cell  already  containing  the  value 
(effectively  renaming  all  occurrences  of  the  temporary  to  use  the  cell  name). 


| Label 

Operator  Operands 

Attributes 

1 ?dest 

store  <?source> 

?dest:classstemporary 

1 ?dest 

ALIAS  ?source 

The  next  two  transformations  translate  the  store  Instruction  to  the  appropriate 
machine  Instruction,  depending  on  the  type  of  the  destination. 


Label 

Operator  Operands 

Attributes 

|?dest 

store  ?source 

?dest 

mov  Tsource 

conditions:  equal[<?dest>:type,"integer"] 

equalf<?source>:type, "integer"] 

Label 

Operator  Operands 

Attributes 

?dest 

store  ?source 

?dest 

movf  ?source 

conditions:  equal[<?dest>:type,,,rear'] 
equal[<?source> ; type, "real"] 


These  two  transformations  "overlap'1  the  first  - program  fragments  matched  by  the 
first  transformation  will  also  be  matched  by  one  of  the  other  two  transformations. 
It  is  up  to  the  metainterpreter  to  decide  which  of  the  applicable  transformations  to 
apply;  presumably  the  first  transformation  will  be  used  whenever  possible  because 
of  the  reduced  cost  of  the  resulting  code.  The  final  transformation  accommodates 
store  statements  whose  source  and  destination  have  different  types. 


Label 

Operator 

Operands 

Attributes 

|?dest 

store 

?source 

?t1 

convert 

?source 

?t1  :class=temporary 
<?t1  >:type»<?dest>:type 

?dest 

store 

<?t1> 

I conditions:  not[equair<?dest>:type,?source:type]] 
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CHAPTER  FOUR 


$4.1  Examples  a mini-translator 

As  an  example  of  the  IL/ML  system  In  action,  this  chapter  presents  a 
catalogue  of  patterns  describing  the  translation  of  a simple  block-structured 
language  to  a POP  11 -like  assembly  language.  The  initial  IL  program  is  the  program 
to  be  translated,  for  example: 


Label 

Operator 

Operands 

Attributes 

begin 

declaration 

PROG 

A:type=automatic 

H 

declaration 

<A>:type=lnteger  <A>:size=2 
B:type«external 

declaration 

<B>:type*(nteger  <B>.size=2 
C:type>automatic 

H 

assign 

M ^ II 

<C>:type*lnteger  <C>:slze*2 

assign 

••  2" 

T1 

plus 

<A>  <B> 

T 1 :type=temporary  <T1  >:type=integer 

T2 

plus 

<T1  > "0“ 

T2:type»temporary  <T2>:type=integer 

C 

assign 

<T2> 

end 

PROG 

The  Anal  output  of  the  IL/ML  system  Is  an  IL  assembly  language  program  which 
Implements  the  Initial  high-level  (!)  program.  Starting  with  the  program  above,  one 


possible  outcome  might  be: 

global  B 

{declare  B to  be  external 

mov 

•P,r6 

{Initialize  local  frame  pointer 

sub 

04, sp 

{allocate  automatic  storage 

mov 

#1,(r6) 

{perform  assignment  to  A 

mov 

#2,B 

{and  then  assignment  to  B 

mov 

*3,2(r6) 

{next  do  C ■ A+B+0 

add 

04, sp 

{Anally  deallocate  storage 

The  toy  language  used 

in  this  example  Is  very  rudimentary:  the  o 

04. 
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addition  and  assignment;  the  order  of  expression  evaluation  Is  constrained  to  be 
left-to-rlght  (no  reordering  Is  allowed);  all  quantities  are  1 6-blt  two’s  complement 
Integers  (the  same  for  both  the  source  and  machine  language).  In  examining  the 
assembly  language  program,  It  Is  apparent  that  certain  conventions  have  been  used 
In  the  translation:  r5  is  used  as  the  local  stack  frame  pointer,  external  variables 
are  referenced  by  name,  local  (automatic)  storage  for  blocks  Is  allocated  from  the 
stack  and  referenced  using  the  local  stack  frame  pointer,  and  so  on.  These 
conventions  are  established  originally  by  the  designer  and  Implemented  by 
transformations  In  a straightforward  fashion. 

Although  It  is  possible  to  interpretlvely  apply  the  transformations  and  derive 
a translation,  the  reader  should  be  reminded  that  the  main  goal  of  the 
transformations  Is  to  be  descriptive.  Many  of  the  transformations  below  employ 
attributes  and  conditions  that  represent  a reasonable  description  of  the  information 
and  constraints  involved  In  a transformation  - these  transformations  are  not  the 
most  elegant  expression  of  the  necessary  syntactic  transformation.  In  the  final 
analysis,  a transformation  should  be  Judged  on  the  information  It  conveys  and  not 
how  close  It  comes  to  "the  way  It  should  really  be  done." 

The  approach  adopted  for  the  organization  of  the  transformations  Is  as 
follows:  the  initial  IL  program  Is  first  translated  into  Instructions  for  a stack 
architecture,  then  the  updated  program  Is  translated  into  target  machine 
Instructions.  Optimizations  exist  for  each  level  of  Intermediate  program  - sample 
high-level  optimizations  are  described  In  $4.3,  stack  optimizations  in  $4.1,  and 
peephole  machine  optimizations  in  $4.2. 

The  first  group  of  transformations  describes  the  process  of  storage 
allocation.  An  "offset"  attribute  Is  Introduced  for  each  automatic  variable  declared 
In  the  block,  giving  the  variable’s  offset  from  the  base  of  the  local  stack  frame;  the 
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highest  offset  assigned  Is  used  In  calculating  the  storage  to  be  allocated  for  the 
block  when  It  Is  entered. 


Label 

Operator  Operands 

Attributes 

| 

begin  ?name 

enter  ?name:storage 

comment 

offset«0 

In  this  transformation,  the  "begin"  statement  Is  translated  to  instructions  that 
allocate  a stack  frame  of  the  appropriate  size  - the  size  (?name:storage)  Is  known 
to  be  a constant  but  its  value  has  not  yet  been  determined.  The  last  statement  in 
the  replacement  Initializes  the  offset  for  later  transformations  - its  initial  value 
Indicates  that  storage  Is  allocated  anew  for  each  block.  The  comment  operator  Is 
ignored  by  assembler  and  will  be  used  in  the  transformations  as  an  operator  In 
statements  where  only  the  attribute  fields  are  used.  Comment  statements  could  be 
eliminated  altogether  and  their  associated  attribute  definitions  placed  In  attribute 
flelda  of  other  statements;  they  are  used  here  to  improve  the  readability  of  the  IL 
program  examples. 


Label 

Operator  Operands 

Attributes 

|?name 

comment 

$*stat 

declaration 

offset*?off 

?name:type*automatlc 

comment 

?name:offset“?off 
offset=addf  ?off,<?name>:slzel 

conditions:  not[attrlbute["offset=?",$"stat]] 

not[operand[ ■ declaration"  ,$"stat]] 

1 Label 

Operator 

Operands 

Attributes 

||?name 

declaration 

?name:typeBexternal 

global 

?name 

The  two  transformations  above  handle  declaration  processing  - automatic  variables 
are  assigned  offsets,  external  variables  are  declared  global.  In  the  first 
transformation,  offsets  are  propagated  with  the  aid  of  a comment  statement  that 
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Figure  4.1:  Sample  program  after  declaration  transformations 


gives  the  current  offset.  The  $"stat  wild  card  will  match  only  statement 
sequences  that  do  not  contain  an  "offset"  attribute  definition  or  "declaration" 
operator  In  any  statement  (this  restriction  Is  embodied  In  the  condition).  Note  that 
attributes  defined  for  the  declared  variables  will  be  automatically  copied  over  to 
some  replacement  statement  (in  these  cases,  there  is  only  one). 


Label 

Operator  Operands 

Attributes 

1 

comment 

$*stat 

end  ?name 

offaat“7off 

exit  7name -.storage 

comment 

?name:storaae=#?off 

conditions:  not[attrlbute["offset=7",$*stat]] 

not[operator[lldeclaratlon",$*stat]] 

This  transformation  handles  block  exit  after  all  declarations  have  been  processed, 
deallocating  storage  for  the  block  and  defining  the  storage  size  attribute 
(?name:storage)  for  use  during  block  entry.  The  condition  Is  similar  to  that  for 
automatic  variable  declarations.  Figure  4.1  shows  the  IL  program  after  these 
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Label 

Operator 

Operands 

Attributes 

enter 

comment 

PROG:storage 

offset-0 

registers={RO  R1  R2  R3  R4) 

comment 

A:type=automatlc  A:offset=0 
<A>:type*integer  <A>:slze=2 
offset=2 

global 

B 

B:type=external 
<B>:type=lnteger  <B>:size=s2 

comment 

C:type=automatic  C:offset=2 
<C>:type=lnteger  <C>:size*2 
offset*4 

push 

N^N 

Pop 

<A> 

push 

H2  M 

pop 

<B> 

push 

<A> 

push 

<B> 

add 

T1:type=temporary  <T1>:type=integer 

push 

"0" 

add 

pop 

<c> 

T 2:type*temporary  <T2>:type*integer 

exit 

comment 

PROG  storage 

PROG  :storages#4 

Figure  4.2:  Sample  program  after  translation  to  stack  machine 


transformations  have  been  applied. 

The  next  two  transformations  translate  "plus"  and  "assign"  to  stack 
operations.  The  Information  In  the  label  Held  Is  incorporated  Into  the  operand  Held 
of  the  new  Instructions  and  the  three-address  "plus"  operation  Is  expanded  Into  a 
series  of  one-address  stack  operations.  Type  considerations  are  Ignored;  In  this 
case,  propagation  of  the  "integer"  type  attributes  would  not  change  the  code 
generated. 


Bffm 

Attributes 

|?deat 

assign  ? source 

nra 

08. 
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Label 

Operator  Operands 

Attributes 

|?dest 

plus  Topi  ?op2 

push  ?op1 
push  ?op2 
add 

pop  <?dest> 

The  following  two  transformations  perform  simple  optimizations  on  the  stack 
machine  code  generated  so  far.  Both  transformations  improve  on  pop/push 
Instruction  pairs  that  have  identical  operands:  the  first  transformation  eliminates 
pairs  whose  arguments  are  temporaries;  the  second  transformation  converts  pairs 
whose  arguments  are  variables  to  a copy  from  the  top  of  the  stack.  Since 
temporaries  were  generated  by  the  compiler  and  do  not  represent  user-visible 
quantities,  they  may  be  eliminated  during  optimization.  Figure  4.2  shows  the 
example  IL  program  after  translation  to  stack  Instructions. 


I Label  | 

Operator  Operands 

Attributes 

■ 

[£SHBKrT]|HH 

I3lM  mHFm 

conditions:  equal[?arg:type, "temporary*] 


Label 

Operator  Operands 

Attributes 

■ 

KG 

155331  ■ti*  ■ 

L_ 

copy  Tara 

$4.2  Compiling  past  the  machine  Interface 

In  this  section,  we  deal  with  translating  stack  machine  programs  to  target 
machine  programs.  The  first  set  of  transformations  are  a straightforward  translation 
of  "push”,  "pop",  "copy",  and  "add”  to  PDP1 1-like  Instructions.  The  size  In  bytes 
and  number  of  storage  references  required  for  each  machine  Instruction  are 
indicated  by  the  "size"  and  "refs"  attributes  respectively. 
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Initial  values  for  the  "size"  and  "refs”  attributes  do  not  take  operands  Into  account 
- the  operand’s  contributions  will  be  Included  when  they  are  translated  to  legal 
assembly  language  constructs. 

The  next  group  of  transformations  translates  Individual  operands  into  the 
appropriate  machine  addresses.  Recall  that  r6  is  used  as  the  base  of  frame 
pointer  and  that  external  operands  are  addressed  by  name. 


Label  | Operator  Operands  I Attributes 


Trator  ?*before  <?rand>  ?*after  slze=?size  refs«?refs 


Trator  ?"before  ?rand:offset(r5)  ?"after 


conditions:  eaual 
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Label 


?rator 


Trator 


erands 


?rand  ?dest 


#?rand  ?dest 


Attributes 


size=?size  rets=?refs 


conditions:  constant 


T"before  and  ?"after  are  ambiguous  wild  cards  used  to  select  any  component  in 
the  operand  Held  that  has  the  correct  form  (specified  by  the  remaining  component 
in  the  pattern's  operand  field).  Note  that  the  specification  of  "size"  and  "refs" 
attributes  in  the  patterns  ensures  that  the  transformations  will  only  be  applied  to 
machine  Instructions.  Figure  4.3  shows  the  IL  program  after  application  of  these 
transformations  (unused  attributes  have  been  eliminated  for  brevity). 

The  most  obvious  optimization  opportunity  Involves  a push  onto  the  stack  (a 
"mov"  instruction  with  a second  argument  of  "-(sp)")  followed  by  an  instruction  that 
pops  the  stack  to  get  Its  source  operand  (an  Instruction  with  a first  argument  of 
”(sp)+").  Since  an  "add"  can  take  the  same  source  operands  as  a "mov" 
Instruction,  the  push/pop  sequences  can  be  reduced  to  a single  instruction: 


Label 

Operator  Operands 

Attributes 

mov  Taource  -(sp) 

Top  (ap)+  Tdest 

slzesTsl?e1  refs=?refs1 
size=?slze2  refs=?refs2 

Top  Tsource  Tdest 

stze=subtract[add[Tslze1  ,Tsize2],"1 "] 
refs»subtract[add[Trefs1,Trefs2],"2] 

Figure  4.4  shows  the  effect  of  this  single  optimization. 

Many  other  machine  level  optimizations  are  possible  at  this  point;  several 
optimizing  transformations  are  listed  below.  These  Include  removing  superfluous 
zeroes  In  Index  expressions,  eliminating  additions  with  a zero  operand,  and 
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Label 

Operator 

Operands 

Attributes 

mov 

ap  r6 

slze=2 

refs=1 

sub 

PROG:  storage 

#P 

slze=4 

refs=2 

global 

B 

mov 

#1  *(sp) 

slze=4 

refs=3 

mov 

(ap)+  0(r6) 

size =4 

refs=4 

mov 

#2  -(sp) 

si2e<*4 

refs*3 

mov 

(ap)+  B 

size*  4 

refs=4 

mov 

0(r6)  -(sp) 

slze=4 

refs=4 

mov 

B -(sp) 

slze=4 

refs=4 

add 

(sp)+  (sp) 

slze=2 

refs=3 

mov 

#0  -(sp) 

size-4 

refs=3 

add 

(sp)+  (sp) 

slze-2 

refs=3 

mov 

(sp)+  2(r6) 

size=4 

refs=4 

add 

PROG:storage 

sp 

slze=4 

refs =2 

comment 

PR0G:Storage=#4 

Figure  4.3:  Sample  program  after  translation  to  machine  instructions 


Label 

Operator 

Operands 

Attributes 

mov 

sp  r6 

slze=2 

refa=1 

sub 

PROG:storage 

sp 

slze=4 

refs=2 

global 

B 

mov 

#1  0(r6) 

slze=0 

refs=4 

mov 

#2  B 

8lze=0 

refs=4 

mov 

0(r6)  -(sp) 

slze*4 

refs*4 

add 

B (sp) 

size>4 

refs«4 

add 

#0  (sp) 

slze=4 

refs*3 

mov 

(ap)+  2(r5) 

slze=4 

ref s=4 

add 

PROG'.storage 

ap 

size=4 

refs=2 

comment 

PR0G:8torage=#4  | 

Figure  4.4:  Sample  program  after  push/pop  optimization 
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Figure  4.6  shows  the  IL  program  after  application  of  these  final  transformations  - 
comment  and  attributes  have  been  omitted  and  attribute  references  resolved. 
Obviously,  additional  transformations  would  be  needed  to  handle  optimization 
opportunities  that  arise  from  the  translation  of  other  programs;  however,  the  bulk  of 
the  translation  can  be  accomplished  with  these  few  transformations. 

$4.3  Interacting  with  the  metainterpreter 

The  transformations  In  the  previous  section  dealt  with  the  translation  of  the 
Input  program  to  a target  machine  program  with  little  attention  to  the  semantics  of 
the  initial  IL  program.  For  the  most  part,  the  metainterpreter  had  only  to  choose 
which  transformations  to  apply  - this  task  was  made  fairly  simple  for,  in  almost 
every  case,  If  the  transformation’s  pattern  and  conditions  were  met,  it  was 
appropriate  to  apply  the  transformation.  This  section  explores  how  the  capabilities 
of  the  metainterpreter  can  be  called  into  play  to  Improve  the  quality  of  the 
resulting  translation. 

The  first  example  exploits  the  metainterpreter's  ability  to  perform  certain 
computations  at  compile  time.  Consider  the  addition  of  the  following  transformations 
to  the  catalogue: 
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Label 

Operator 

Operands 

Attributes 

mov 

sp 

r6 

slze*2 

ref s=1 

sub 

#4 

sp 

slze«4 

ref3«2 

global 

B 

mov 

#1 

(r6) 

alze=4 

refs=3 

mov 

#2 

B 

slze>6 

refs=4 

mov 

(r6) 

*(sp) 

size*2 

refs=3 

add 

B (sp) 

slze=4 

refs=4 

mov 

(sp)+  2(r5) 

size=4 

refs=4 

add 

#4 

»P 

size=4 

refs=2 

Figure  4.6:  Sample  program  after  final  optimizations 


1 Label 

Operator  Operands 

Attributes 

||?dest 

assign  Tsource 

1 ?dest 

assign  7source 

<?dest>=?source 

[Label 

Operator 

Operands 

Attributes 

|?dest 



7op1  7op2 

|7dest 

ihsphbi 

These  transformations  tell  how  the  rvalue  of  the  result  cell  Is  affected  by  the 
"assign"  and  "plus"  operators.  Using  the  definition  of  "add"  given  In  $3.2.2,  the 
second  transformation  will  only  succeed  If  ?op1  and  ?op2  are  numeric  literals.  By 
extending  the  metainterpreter  to  support  symbolic  computation,  both  the 
transformations  above  would  be  useful  even  for  non-literal  operands  (although  the 
second  transformation  should  not  eliminate  the  explicit  plus  operation  unless  the 
add  would  succeed  at  compile  time).  The  primary  benefit  of  such  an  extension 
would  be  a corresponding  extension  in  the  metainterpreter's  ability  to  detect 
redundant  computations. 

Applying  these  transformations  to  the  sample  program  In  the  first  section, 
the  metainterpreter  can  acquire  the  following  rvalue  Information: 

<A>»"1"  <B>«"2"  <T1>«<C>»"3". 

As  a result  of  this  new  Information,  the  initial  program  can  be  modified  as  shown  In 
Figure  4.0  (update  of  Figure  4.2).  By  adding  a transformation  to  eliminate  assigns 
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Label 

Operator 

Operands 

Attributes 

enter 

comment 

comment 

PROG:storage 

offset*0 

A:type=automatlc  A:offset=0 
<A>:type=lnteger  <A>:slze=2 
offset=2 

global 

comment 

B 

B:type=external 
<B>:type=lnteger  <B>:slze=2 
C:type=automatlc  C.offset=2 
<C>:type*integer  <C>:slze*2 
offset=4 

A 

assign 

M ^ II 

B 

assign 

H 2" 

T1 

assign 

"3" 

T 1 :type*temporary  <T  1 > :type=integer 

T2 

assign 

"3" 

T2:type=temporary  <T2>:type=integer 

assign 

exit 

comment 

"3" 

PROG:storage 

PROG  :storage=#4 

Figure  4.6:  Sample  program  after  declaration  transformations 


Label 

Operator 

Operands 

Attributes 

mov 

sp  r6 

slze*2  ref s=1 

sub 

PROG:storage 

sp 

size=4  refs=2 

global 

B 

mov 

#1  (r6) 

slze=4  refs=3 

mov 

#2  B 

slze>6  refs=4 

mov 

#3  2(r6) 

slze=6  refs=4 

add 

PROG:storage 

sp 

slze=4  refs=2 

comment 

PROG:storage=#4 

Figure  4.7:  Sample  program  after  optimizations  of  $4.3 


to  subsequently  unused  temporaries,  the  transformations  of  $4.2  can  produce  a 
program  Identical  to  the  assembly  language  program  given  In  $4.1  (see  Figure  4.7). 
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CHAPTER  FIVE 


$6.1  Summary 

The  emphasis  of  this  thesis  has  been  on  developing  a framework  that  can 
be  used  In  the  specification  of  a code  generator.  The  major  design  goal  for  this 
framework  was  to  segregate  language  and  machine  dependencies  from  the 
remainder  of  the  code  generation  process  while  maintaining  the  ability  to  produce 
optimized  code.  A three  component  system  was  developed  that  makes  a significant 
step  towards  reaching  this  goal.  Although  many  features  provided  by  the  system 
are  In  need  of  polishing  to  remove  their  rough  edges,  the  specification  that 
emerges  seems  to  satisfy  the  initial  design  goal.  The  proposed  system  Is  simple 
compared  to  many  of  the  available  alternatives;  there  are  no  severe  restrictions  on 
the  class  of  languages  or  machines  that  can  be  accommodated. 

Chapter  2 describes  a general  purpose  Intermediate  language  based  on  a 
semantics  common  to  a wide  class  of  programs:  the  only  primitives  concern  flow  of 
control  and  management  of  names  and  values.  The  syntax  has  been  designed  to 
o*mcm  information  important  to  optimization  algorithms  In  separate  fields  so  at  to  be 
. mom  m the  metewterpreter  without  a detePed  analysis  of  the  actual 


Of  control  and 


allows  it  to  be  referenced  by  the  transformations,  permitting  the  translation  of 
statements  to  be  tailored  In  response  to  special  properties  of  the  operands  or 
opportunities  presented  by  the  context. 

In  Chapter  3,  the  transformation  catalogue  is  discussed  and  the 
metalanguage  In  which  the  Individual  transformations  are  written  is  presented.  The 
metalanguage  provides  the  ability  to  describe  classes  of  IL  program  fragments, 
leaving  statements  and  components  unspecified  through  the  use  of  wild  cards. 
Each  transformation  contains  two  ML  program  fragments  (templates):  a pattern  that, 
along  with  a set  of  conditions,  specifies  the  IL  program  fragments  to  which  the 
transformation  can  be  applied,  and  a replacement  that  tells  how  to  construct  an 
updated  IL  program.  Built-in  functions  that  allow  access  to  some  of  the 
metainterpreter’s  knowledge  about  IL  programs  and  perform  some  simple 
computations  on  literals  are  provided  - these  functions  are  used  In  constructing 
the  replacement  and  conditions.  The  conditions  associated  with  a transformation 
specify  contextual  constraints  that  are  not  related  to  the  syntactic  form  of  the 
matched  fragment.  The  wide  range  of  Information  available  to  a transformation 
enables  the  semantics  of  code  generation  to  be  expressed  as  step-by-step 
syntactic  transformations  of  the  intermediate  language  program. 

Chapter  A presents  a set  of  example  transformations  as  a specification  for 
translating  a rudimentary  source  language  to  POP  11 -like  assembly  language.  As 
suggested  in  $1.3.1,  the  transformations  are  organized  about  the  use  of  an 
abstract  machine  (In  this  case,  with  a stack  architecture).  The  Initial  translation  to 
stack  machine  Instructions  allows  several  optimizations  to  be  accomplished  that 
woWd  have  otherwise  been  mthruM  (a  g . the  remove!  of  unnecessary  temporaries 
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optimize  the  resulting  code  are  Included  In  the  catalogue,  performing  several 
operations  at  compile  time  that  had  previously  appeared  in  the  final  assembly 
program.  Although  the  example  la  fairly  simple,  It  demonstrates  the  feasibility  of 
the  proposed  approach  to  code  generation. 

The  final  component  of  the  proposed  framework  - the  metainterpreter  - has 
only  been  alluded  to  In  the  previous  chapters.  The  next  section  provides  a brief 
overview  of  the  capabilities  the  metainterpreter  needs  to  supply.  The  final  section 
of  this  chapter  points  out  several  directions  In  which  subsequent  research  might 
head. 

The  most  Important  contribution  made  by  this  research  Is  the  design  of  an 
Intermediate  language  that  caters  to  the  need  for  the  careful  data  flow  analysis 
that  is  the  foundation  of  many  optimizations.  In  contrast,  many  so  called  portable 
code  generation  schemes  sacrifice  the  ability  to  do  any  substantial  processing 
during  code  generstlon  to  achieve  their  portability.  The  type  of  processing  needed 
to  be  done  by  an  optimizing  code  generator  is  becoming  more  systematized:  recent 
advances  In  the  theory  of  code  generation  have  provided  algorithms  where  only 
heuristics  existed  previously  and  there  Is  promise  that  these  advances  can  be 
extended  to  the  problems  of  real  languages.  The  approach  to  code  generation 
proposed  by  this  thesis  would  allow  these  advances  to  be  Incorporated  without 
extensive  editing  of  existing  specifications. 

$6.2  An  overview  of  the  metainterpreter 

Throughout  earlier  portions  of  this  thesis  the  metainterpreter  has  been 
assigned  tasks  whenever  they  can  be  divorced  from  the  semantics  of  the  source 


tasks.  The 


• translation  of  attribute  references  to  their  corresponding  values 
wherever  possible.  If  any  unresolved  attribute  references  remain 
after  completion  of  the  transformation  process,  the  metainterpreter 
should  abort.  Indicating  an  Inconsistent  IL  program. 

e evaluation  of  built-in  functions.  If  a function  application  aborts  (e.g., 
because  of  domain  errors),  It  Is  saved  for  reevaluation  later  In  the 
translation. 

• propagation  of  rvalue  Information.  In  combination  with  data  from  flow 
analysis,  It  Is  possible  to  replace  rvalue  operands  with  literals 
representing  the  known  value  of  the  rvalue. 

e application  of  a chosen  transformation.  Information  obtained  during 
the  match  of  the  pattern  Is  Incorporated  In  the  replacement 
specification  (along  with  any  generated  symbols)  to  create  a 
replacement  for  the  target  statements  In  the  pattern.  During  the 
construction  of  the  replacement,  many  of  the  other  bookkeeping 
functions  can  be  performed  then  and  there,  eliminating  the  need  for 
extra  passes  over  the  IL  program. 

Two  other  tasks  fall  in  this  area:  checking  for  termination  conditions  and  choosing 
which  transformation  to  apply  next. 

$1.3.2  outlines  how  to  tell  when  the  translation  is  complete:  a measure  of 
the  programs  optimality  Is  computed  using  a formula  (In  this  case,  Involving  the 
values  of  attributes  associated  with  every  statement)  supplied  by  the  user  - if  the 
calculation  aborts  because  some  statement  does  not  have  the  appropriate 
attributes,  the  application  of  more  transformations  is  called  for;  If  no  more 
transformations  are  applicable,  backtracking  Is  called  for.  If  the  measure  can  be 
computed.  It  is  used  to  remember  the  best  translation  found  to  date  and  the 
metainterpreter  backtracks  to  find  other  translations.  Backtracking  Involves 
undoing  the  last  successful  transformation  and  applying  some  other  transformation 
(repeating  for  another  level  If  all  the  applicable  transformations  have  been  applied 
at  this  level).  Exhaustive  search  of  the  transformation  tree  can  be  avoided  If  the 
ueer  supplies  a "trigger"  value  for  the  measure  - any  program  whose  measure  is 
tees  *han  the  trigger  value  is  oonsMered  an  acceptable  translation  and  becomas 


Often 


first  successful  translation  will  be  acceptable  (an  Infinite  trigger  value). 


There  are  many  ways  In  which  to  choose  the  next  transformation  to  apply: 
the  simplest  is  to  search  the  transformation  catalogue  for  a transformation  that  is 
applicable  to  some  portion  of  the  current  IL  program.  A more  satisfactory  scheme 
Involves  completing  the  translation  of  the  beglnlng  portions  of  the  IL  program  before 
moving  on  to  later  portions  In  the  hope  that  optimizations  will  eliminate  the  need  to 
translate  some  parts  of  the  program.  Cycles  In  the  flow  graph  may  require 
translation  (at  least  In  part)  of  portions  of  the  program  that  will  eventually  be 
eliminated.  Sophisticated  use  of  the  transformation  catalogue  requires  a good 
understanding  of  the  effect  of  each  transformation,  an  understanding  that  may  be 
difficult  to  achieve  (see  the  comments  on  metacompllatlon  at  the  end  of  $6.3). 

Flow  analysis  Is  necessary  for  many  of  the  optimizations  Incorporated  In  the 
mstalnterpreter  and  Is  doubly  Important  as  these  optimizations  form  the  basis  for 
replacing  the  manual  analysis  conventionally  applied  to  determine  special  code 
generation  cases.  It  Is  common  for  transformations  to  do  a "sloppy"  Job  of 
translation,  Incorporating  explicit  tests  In  the  expanded  code  rather  than  iterating 
transformations  with  different  contexts.  The  optimizations  listed  below  are  capable 
of  Improving  such  code  to  the  quality  of  code  produced  by  human  programmers 
writing  in  low-level  languages  [Carter].  The  optimizations  Include 

e constant  propagation.  This  optimization  assumes  lesser  Importance  in 
the  IL/ML  system  since  attributes  provide  much  of  the  information 
commonly  embodied  as  constants  In  other  general  purpose  optimizing 
compilers. 

e dead  code  elimination  - code  that  can  no  longer  be  reached  during 
execution  can  be  removed  from  the  IL  program  (remembering  to  save 
any  attribute  definitions  somewhere  else). 

e redundent  expression  aMmfnatton.  Simple  determination  of  the 
redundancy  of  a statement  oan  be  ecoompdehed  by  a straightforward 
lasieei  Bsmpartssn  of  statements  bnown  to  proceed  (to  aeocottan) 
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possible  when  rvalue  Information  is  considered. 

There  are  other  related  optimizations  requiring  the  same  data  flow  Information. 

The  required  flow  analysis  could  be  done  anew  at  the  completion  of  every 
transformation  application  but  this  would  be  Incredibly  Inefficient  - prohibitive  for 
large  programs.  The  bit  vector  methods  outlined  by  [Schatz]  and  [Ullman]  offer  an 
efficient  representation  of  the  data  flow  Information  that  can  be  Incrementally 
updated  as  long  as  the  underlying  flow  graph  Is  not  changed  (except  to  add/delete 
more  straight-line  code  or  loops  completely  contained  In  the  added  code).  Thus, 
the  more  time  consuming  Iterative  calculation  required  when  the  flow  graph  Is  not 
known  need  only  be  performed  when  a transformation  affects  the  branches  and 
joins  of  the  graph.  A large  percentage  of  transformations  do  not  affect  the  graph 
Itself  - all  of  the  transformations  in  Chapter  3 could  be  accommodated  by 
Incremental  analysis. 

In  a different  vein,  code  motion  out  of  loops,  elimination  of  Induction 
variables,  etc.  (see  [Aho77b]  for  a large  sample)  represent  other  optimizations  that 
could  be  Incorporated  In  the  metainterpreter.  As  algorithms  are  developed  for 
register  allocation  and  optimal  ordering  of  expression  execution,  these  will  also  be 
prime  candidates  for  inclusion.  Our  shopping  list  can  easily  grow  must  faster  than 
our  ability  to  implement  the  algorithms  effectively  within  the  framework  provided  by 
the  metainterpreter.  Fortunately,  some  transformations  are  much  more  Important 
that  others;  the  list  given  under  flow  analysis  is  a good  start  towards  an  excellent 
code  generator. 

$6.3  Directions  for  future  research 

Two  avenues  of  research  are  natural  extensions  of  the  work  reported  here. 
The  anosmias  of  Chapters  3 and  4 indicate  that  siueh  improvement  oould  he  made 


cod*  generation  (allocation  of  storage,  register  assignment,  etc.)  could  benefit  from 
direct  support  In  ML,  eliminating  the  need  for  hard-to-decipher  transformations. 
Several  suggestions  are: 

* the  Inclusion  of  a structure  mechanism  for  laying  out  storage. 
Providing  a general  purpose  allocation  scheme  would  allow  the 
metainterpreter  to  shoulder  the  responsibility  for  assigning 
successive  offsets  and  summing  the  storage  requirements.  If  the 
syntax  Is  modeled  after  provided  by  modern  high-level  languages  for 
variable  declarations,  there  would  be  provision  for  variable  size 
components  and  alignment  constraints. 

* support  for  the  notion  of  temporary  locations.  Many  machines  have 
some  special  storage  facilities  that  are  particularly  appropriate  for 
use  as  temporary  locations  - registers,  stacks,  etc.;  for  machines 
with  no  such  facilities,  temporary  locations  could  be  assigned  from  a 
pool  In  ordinary  storage  managed  at  compile  time  by  the 
metainterpreter.  It  should  be  possible  to  separately  describe  the 
allocation,  use,  and  deallocation  of  temporary  locations;  a distinct 
syntax  could  then  be  used  In  the  ML  program  to  bring  this  mechanism 
Into  play. 

* adding  the  ability  to  expand  user-defined  procedures  In  line.  This 
capability  Is  related  to  the  current  Inability  In  ML  to  deal  with  groups 
of  statements  (procedures,  subtrees,  etc.)  that  do  not  follow  one 
another  during  execution.  The  ability  to  perform  compile  time 
substitution  of  actual  arguments  for  formal  parameters  is  also  missing 
- such  an  addition  would  allow  partial  evaluation  of  procedures  at 
compile  time. 

Accumulating  a variety  of  such  optional  features  would  greatly  enhance  the 
capabilities  of  ML  without  restricting  its  generality. 

The  second  major  area  for  future  research  la  the  Implementation  of  a 
metainterpreter  and/or  metacompiler.  The  Experimental  Compiler  Group  at  the  IBM 
Thomas  J.  Watson  Research  Center  [Harrison]  has  implemented,  with  some  success, 
a compiler  (the  GPO  compiler)  baaed  on  a similar,  although  more  restricted,  scheme. 
The  GPO  compiler  alternately  applies  transformations  to  remaining  high-level 
operatione  and  optimizes  the  current  Intermediate  program.  A similar 
straightforward  Implementation  effort  for  the  H7M.  system  would  have  similar 


program  could  lead  to  a very  competent  compiler  that  Is  easily  maintained  and 
modified  to  produce  code  for  different  target  machines. 

Many  other  Implementation  approaches  lie  further  off  the  beaten  path.  One 
of  the  most  interesting  Is  the  prospect  of  creating  a "compiled"  code  generator 
based  on  an  analysis  of  the  specification.  Such  compilation  would  require 
extensive  Information  on  the  Interaction  between  components  of  the  specification; 
the  metacompiler  would  have  to  "understand"  the  effect  of  each  transformation  In  a 
much  more  fundamental  way  than  Is  needed  from  an  Interpretive  approach. 
Compiling  the  specification  would  eliminate  much  of  the  searching  and  backtracking 
described  in  the  beginning  of  $6.2  with  the  result  of  a vast  Improvement  In  the 
performance  of  the  code  generator.  The  metacompilation  phase  will  almost 
certainly  be  necessary  If  the  performance  of  our  code  generator  Is  to  approach 
that  of  conventional  ad  hoc  code  generators. 

Metacompilation  Is  closely  related  to  current  work  in  the  field  of  automatic 
program  synthesis.  The  specification  provided  by  the  IL/ML  system  has  many  of 
the  same  characteristics  as  descriptions  used  In  these  synthesis  systems  [Green]: 
a pattern-based  transformation  system  is  used  as  the  knowledge  base  by  both 
systems.  This  commonality  promises  to  allow  many  of  the  same  techniques  to  be 
used  In  the  analysis  of  the  specification.  This  area  of  research  Is  still  virgin 
territory  with  the  same  promises  of  success  and  failure  offered  by  any  frontier. 
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